Update: There’s a slightly extended version of this post over at the INNOQ company blog.
There, I said it. Now that I have your attention: 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 at INNOQ. And in contrast to my click-bait headline, I’m actually a fan. Eric Evans’s book, the additional work writing and evangelizing it done by Vaughn Vernon (e.g. in this very good podcast with my colleague Joy) and many others, are all 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.
I think 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 to me 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.
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.