Or why DDD is my silver bullet.
Yep, I said the word “Silver Bullet”. All the trolls are now out of their cave ready to hurt me with their clubs. But before hitting me, have a cup of coffee, relax and read on.
Where is the paradox?
In every book and every conference about DDD, I hear “DDD is not a silver bullet”. I might be the only one to think the opposite. Thus I probably miss something.
Still, since the very start of my quest to learn about DDD, I use it on every project. Even on easy cases where a CRUD implementation is good enough.
Because to understand my domain and decide if CRUD, is good enough, I interview domain experts.
I may do one or two event storming sessions when possible. I try to understand the subdomains and see how they are aligned with my bounded context. I crunch knowledge to identify the core domain. This is where strategic patterns from DDD are essential to help me understand the context, in order to decide if it’s appropriate to apply DDD.
You need it when you don’t need it
You see the paradox ? I need DDD strategic patterns to understand a domain deeply enough, to decide whether DDD tactical pattern are relevant, if any. Said another way: strategic patterns are useful to understand any domain, whereas tactical patterns may not be relevant to your context.
CQRS is definitely not a silver bullet, neither are Event Sourcing, Repositories, Entities or Value Object. But DDD in its strategic aspects (domain analysis, bounded context, etc) is pretty much useful all the time.
But sometimes you can’t use it
Perhaps there’s a limit to that, as brilliantly explained by Liz Keogh at DDD Europe 2016. She did an amazing talk about the Cynefin framework. When you are in the chaotic area of the framework, it may not even be possible to analyze the business with strategic patterns or any other tools, because any analysis is not even possible. You’re left to act first, and then sense and respond.
But as a consultant, I was never called (yet) to help in such a chaotic environment, or I never recognized it. I’m Usually called to work on legacy systems built with too much technical focus and little analysis of the domains, all this in a complex business domain. And of course it’s not documented and should evolve quickly. Each time DDD Strategic patterns help me to do better diagnostics, faster.
DDD should be verywhere?
Even on the implementation side of a project, there is a lot from DDD that is always usefull. It’s not always about CRUD or CQRS and Event Sourcing. But it’s always about naming the methods, classes, interfaces and modules according to the domain language, the Ubiquitous Language. This is DDD.
If I encourage collaboration between technical and domain experts and work iteratively to refine a conceptual model, I can claim I’m doing DDD.
If thanks to this close collaboration we can find out early that the software we want to build is not critical for the business, I can still say I’m doing DDD. It could save money for the company, for example by chosing a generic off-the-shelf solution, or by deciding to build a quick CRUD solution.
Eric’s plan to conquer the world
This is the DDD paradox, DDD is an approach that even helps you determine when you don’t need it, which makes it pretty much universal. A universal approach seems like a silver bullet to me.
Well played Eric, I start to understand your schemes.
Thank you Cyrille Martraire for your awesome review.