I'm not keen on this word. "Grooming". I've been doing it (sort of) long before I've learned about the thingie named Scrum, but until this very day I haven't convinced myself to call it that way. Grokking domain, crunching through problems, knowledge mining, functional decomposition - all these work better...
A few days ago, I started reading "Semantic Software Design" [https://www.amazon.com/Semantic-Software-Design-Practical-Architects-ebook/dp/B07YCW51DJ] by Eben Hewitt. I haven't finished it yet, but I believe I can already state that it won't become my favourite book on software architecture ever (more about that in the forthcoming review...
> In this article you'll find: what is "capability", why UI-driven application design is sh*t, why conceptual layering is important, which parts of software are less change-friendly & whether it's a problem, why "fibers" are the single worst anti-pattern (even if you hadn't heard about them until now ...). I don't even...
> In this post you'll find: how sharding can work (well) together with CQRS, what tricks can be used for re-partitiong data in live instances (w/o downtime) and why it's OK to use domain-related data in routing on API gateway This is the 2nd post in the series. The first...
> In this post you'll find: micro-monolith neo-evangelism :), great (video) example of premature system distribution hitting the fan ..., demystifying of microservice independence myth and what are X-centric systems. I hate blog posts, books or conf talks that focus on criticising only - it's far easier to b*tch on something than...
> TL;DR Contrary to the common belief, proper conceptual decomposition of large software solutions doesn't require any particular architecture patterns in place. Being service-oriented doesn't necessarily enforce any constraints on build or deployment - it's a matter of proper, highly aware design which can't be conducted in a correct way...
