I recently published a post with the clickbait title “DDD is overrated”, and it generated quite a bit of interest. This is a slightly expanded version, incorporating some of the feedback I received both internally as well as on social media (e.g. here on Twitter, or here on Hacker News). I also reduced the attention-seeking level of the title a bit to reflect that I’ve added a bit more nuance to my thinking.
Domain Driven Design (DDD) has recently gained additional popularity, as evidenced by new books, conference talks, and even complete conferences dedicated to it), and lots of trainings – including some by our very own colleagues here at INNOQ. But while I’ve been a fan of the approach for a long time, I’ve recently become annoyed by the way it’s treated by some poeple. I’m not talking about Eric Evans’s original book, the additional work writing and evangelizing it done by Vaughn Vernon (e.g. in this very good podcast with my colleague Joy Heron), and many others, including Mathias Verraes, Daniel Terhorst-North, or my own colleagues Michael Plöd and Eberhard Wolff. These people, and many others in the DDD community, all contribute very good additions to our industry’s body of knowledge. In the best sense of pattern languages, DDD gives clear names to things that many developers and designers know how to do, but cannot reliably and compatibly communicate about.
But I’m annoyed by the fact that recently, it seems that any time somebody talks about how to architect system or service boundaries, or even just mentions non-technical design, everybody feels compelled to bring in the DDD experts – as if they were the only superheroes who could possibly design anything at all. This is just as bad as any other situation where you blindly apply the solution that’s currently en vogue, just because it is the thing everyone talks about, and not because it is the right solution for the job. DDD is great, but it’s just one of many tools and techniques you should be aware of.
In DDD’s strategic dimension, the tool used most often is the concept of a Bounded Context – the idea that a given model can, and often should, be subdivided into smaller units that each assign their own, context-specific meaning to certain concepts. That’s a great idea! It’s also (of course) not a DDD invention: It’s simply modular design, and it’s been applied by people designing large systems for literally decades. Does that mean that there’s something wrong with the idea of a bounded context? No, and in fact it’s a pattern’s purpose to give a name to something that has existed and proven its value for a while. I’m not claiming there’s anything wrong with a bounded context, all I’m pointing out is that somebody might have created a fantastic design for a system without using, or even knowing, this particular label.
In the tactical dimension, there is a more important aspect that people miss, especially when they get into DDD as their introduction to design in general. DDD emphasizes the importance of naming, and it suggests you should strive for a common, ubiquitous language, in the context you’re designing for. But it also uses its own language – concepts like bounded context, aggregates, entities, value objects, etc. – for our domain, the domain of designing systems. And while these are all well and good, they’re only one possible language. There’s value in calling a value object a value object, if this is a term many people understand, to facilitate communication. But the existing, common DDD concepts are not the only concepts you should consider – they are just examples of a very common trait of designing and architecting systems: Coming up with and recognizing patterns, giving them good names, and using them to give the system structure and integrity. If in your architecture, there’s a common pattern that you use a Filter to route requests to a Handler, or a concept of a Document that is handled by an Agent, then these things may occur again and again, on the same level as Services or Repositories, and end up being way more important to you. This is fine!
This concept, that we can and should invent our own languages, is way more important than many naïve DDD practitioners think. I like to believe that DDD experts know this very well, and view any DDD material as a starting point, not an end result. But if all you’re doing is applying the by-the-book definition of existing DDD terms, and trying to shoe-horn any problem into this existing structure, yours is a very sad designer’s life.
Make DDD part of your tool set, but make sure you don’t stop there. There is a life beyond DDD. Not every good design needs to be Domain-driven (though I can accept it should always be driven by the domain, just not necessarily in the DDD sense). You can design good systems even if you’re not a DDD expert.