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.
Thanks very much for the shout-out, and for an excellent blog post.
I find it fascinating that you’re using DDD to work out if you need DDD. It parallels a similar journey we’ve been making over in the BDD world: http://lizkeogh.com/2014/07/29/using-bdd-as-a-sensemaking-technique/ – maybe there are similar patterns for DDD? I’m wondering now what kind of symptoms you can spot when modelling that tell you that the model will be emergent.
The other interesting aspect of using BDD as a sensemaking tool is the “boring” side, where it’s not worth having the conversations (“user registration” being my typical example). I imagine there are probably situations where the DDD models are also so well-known that it’s not worth the modelling workshop.
I’m also wondering whether there are other manual processes (like software development itself) that would benefit from a DDD approach, helping to reverse Conway’s law; this is something I’ve been looking at from a BDD perspective using real-life examples and scenarios, but I suspect some of the DDD community’s modelling techniques might be relevant too…
Thank you for prompting some very interesting thoughts!
Totally agree.
In the company I’ve been working for last year they only did so-called DDD projects. What they meant was every project needs to use cqrs/es, aggregates, commands, the whole lot of tactical patterns out there. At the same time they did not want developers to talk to the business directly.
My job in that last year was always to advise against using all of those fixed tactical patterns but instead insist on talking to a domain expert, try to come up with a UL, use value objects everywhere. Keep things separate and simple. Create anti corruption layers when communicating to external services. These things.
That’s DDD. I haven’ t created one aggregate in the last year. Not because they’re not useful, but simply they don’t fit the projects we did. That also is DDD.
Greetings
Jan
Emilien, as you already know, I more than agree with every word here. DDD is the way all information systems should be designed. The Tactical Patterns may lead astray, but the Strategic Patterns are essential for every project.
#NoTacticalPatterns 😉
Familiar faces and friends in the comments, so nice 🙂
I wrote a similar post some time ago https://medium.com/@zimareff/ddd-all-the-things-b075be2107dc
Totally agree. This misconception of DDD as a bunch of tactical patterns is really unfortunate, but I think the trend is positive.
Plus, I now tend to think that EventSourcing is really another silver bullet. Well, not really for _everything_ but for most of my stuff I use it and when I don’t – I regret it.