Why Domain Invariants are critical to build good software?

Why Domain Invariants are critical to build good software?

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…

Read More

How to use Side Effects to improve your Domain Modeling?

How to use Side Effects to improve your Domain Modeling?

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…

Read More

What does boxed catering have in common with model entropy?

What does boxed catering have in common with model entropy?

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…

Read More

Of all kinds of crappy code I've ever seen ...

Of all kinds of crappy code I've ever seen ...

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…

Read More

How not to hurt yourself while building a RESTful API

How not to hurt yourself while building a RESTful API

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"…

Read More

Role of technical excellence in DDD?

Role of technical excellence in DDD?

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…

Read More

False prophets in the Domain world

False prophets in the Domain world

Do you know any software craftsmanship practitioners who got fascinated by DDD? By its cleaniness, simplicity or completeness? People who have found the way proposed by Evans their missing tool for describing complex domains in a simple way? I know quite a few & I believe you do as well. Where are these DDDers? But how many of those people do actually apply these practices of DDD on the daily basis? I mean really do apply, not "just adapt some elements we've found possible in our case". Surprisingly few in my case. In yours as well? I'm not…

Read More

Dancing with domains - DDD Europe 2016

Dancing with domains - DDD Europe 2016

I've already promised myself some time ago: "No more conference reviews, chap." But I'll start 2016 with breaking this rule once again, just so I can tell you that ... DDD Europe 2016 was way better than I expected. No worries though, I'll try to be as brief as possible: Guys (& gals?) of DDD Belgium have proven that they are no pushover, but the strongest DDD community in the Old World (at least) - they've not only organized a good conf, brought good speakers (i.e.: Evans, Vernon, Brandolini, Young, etc.) aboard, but they have also delivered a…

Read More