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 remember where & when I've written those words down. It was one of the conferences or meet-ups I keep attending regularly, but I can't recall which one. It doesn't matter though, the point is that I've noted down one-liner that is striking enough to near-perfectly phrase what I was…
All posts in “Design”
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 post can be found here. Real life, hello? Let's consider 4 sample scenarios: SaaS HR system - used by various client-companies for their internal operations On-line marketplace - hundreds of vendors, hundreds of thousands of buyers Live-traffic map - geospatial data is collected from vehicles, anyone can watch (regardless of…
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 propose an actual solution to non-trivial problems. That's why after my recent post (on why microservices may not be an optimal answer to all of your growth problems), I'd like to re-visit an architectural pattern almost as old as Computer Science in general, in fact, a very under-appreciated one ... Sharding.…
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 without proper understanding of concepts like: capability, boundary, identity & role exclusiveness. Disclaimer 1: this is not a post about microservices, this one is about importance of design & proper decomposition of problems you're facing. Sometimes these're the most "obvious" topics that cause the most confusion. The concept…
TL;DR Software Engineers see world in patterns, they look for common denominators, not accepting the fact that something may be an one & only instance. That's why we sometimes end up building frameworks for single problem occurrences ("we'll gonna need it in future") or try to squish accidentally similar concepts into one, common form - ignoring the fact that Domain experts don't recognize this similarity (it has no advantage in terms of domain, it doesn't constrain real-world domain development). The proper answer is (of course) to fight off instinct of pre-mature generalization & ... duplicate. It always starts…
TL;DR Decomposition of functional requirements into atomic User Stories doesn't mean that activity of elaborate design is redundant - there's always a need of shaping the system's conceptual model: usually at various levels of detail (for different reader categories) & taking into account both static and dynamic perspective. Modern design is not sequential, but continuous and likely more flexible in terms of form, but letting it "just emerge" from context-less User Story implementations is a grave mistake. On several occasions I've criticized the way "lowly conscious" applying of Agile methods (w/o truly embracing Agile…
TL;DR Getting end-users' and sponsors' feedback is crucial if you really want to build (/enhance) a good product, but it doesn't mean that you can let them "think with solutions" and mindlessly introduce suggested changes yourself. Business insights ought to be reforged into highly conscious & thoughtful updates of the model beneath the solution first - otherwise the Frankenstein of a system you'll end up with may not only be hard to understand, maintain or develop further, but also devoid of clear focus & uniqueness that made your end-users love it in the beginning. These are universal…
I strongly believe in emerging design & evolutionary architecture. I've seen too much in my life ;> to believe in up-front design & beautiful pictures turning miraculously into flawless, working systems. I'll save you detailed reasoning as I've written about that on several occasions already in the past. Let's consider the emerging design instead, because I've seen many people struggling with the idea which seems so easy at the first glance: how to make it work? what are the pre-requisites? what should be avoided? Contrary to the common belief, emerging design is not about taking it easy or going with…