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…
All posts in Domain Driven Design
TL;DR My expectations regarding software craftsmanship conferences are constantly evolving towards more focused & interactive events. Less novelties (one can learn from Internet on the very next day anyway), more warstories & workshops with seasoned practitioners. DDD Europe 2018 was such an event - dedicated to domain modeling & design in general, with majority of sessions in a form of hands-on workshop. I strongly encourage all people deeply involved in building software not only to learn more about Domain Driven Design in general, but also consider the participation in next year edition. Time for a change This year I've…
TL;DR All systems (according to systems theory - that means computer software, but also board game, biotope or set of objects that are subjects to the basic law of physics) have some underlying "rules of the game" as a foundation - these invariants are used to derive more specific scenarios / cases. Trying to model the system w/o learning these invariants leads to wrong understanding & shaky foundations. What is more - trying to reverse engineer them is a huge effort w/o guaranteed success. Some time ago, during a long discussion regarding different aspects of design…
TL;DR Domain events aren't just a fad, aimed to force asynchronous communication for the sake of being more "reactive" - this is an underappreciated modelling pattern that helps in putting a clear separation between what is the precisely defined business logic & what is the side effect, out of boundaries of current context. Lack of understanding herein may cause excessive complexity in functional areas of the greatest interest - most likely, your Core Domain ... One the goals of my recent WG.NET presentation about coupling was to emphasize that coupling is not only about loosening dependencies between…
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…
TL;DR "It's the domain modelling, stupid!" - Bill Clinton could have said if he were into software engineering. We tend to focus on technical design excellence (patterns, inversion of control, reactivity) without giving much thought to proper, maintainable domain model behind. Consequences are barely visible initially, but their impact grows exponentially when application scales up (not in terms of traffic but accumulated functionality) - this is what impedes industry behemoths' cycle time far more severely than dated technology or waterfallish processes. I think I've seen some crap in my life. Hardcore legacy. Sheer bad engineering. Technical debt…
Well-built service API may be a game changer. In both client-server & server-server scenario, especially if you're following the latest trend of building fine-grained, loosely coupled (micro)services. I've seen several attempts, in different languages, for different domains & running on different platforms - regardless of these differences, there are some common anti-patterns & mistakes that could quite easily be avoided. My goal in this blog post will be to list the ones I find most meaningful & not-that-obvious. Before I get into details - keep in mind that each situation is different - there's no "golden template"…
Here comes another post in "remarks from awesome DDD Europe 2016" series. If you find it boring or not really revealing, I'm the one to be blamed - some ideas, especially related to modelling & design are truly hard to convey. Many software developers are really hooked up by DDD - pretty much everyone I know who's enthusiastic about DDD is a software developer, and believe me - I know many analysts, product owners, SMEs, etc. - people who play various roles, are responsible for different area within a process of creating IT products. But no-one but developers…