Starting into DDD is hard, even though it’s heavily praised by their practitioners. The topic is widely covered in the now infamous “Domain Driven Design” by Eric Evans (Blue Book) and “Implementing Domain Driven Design” by Vaughn Vernon (Red Book).
Both of them are terribly verbose and thick, which is no surprise coming from Java engineers. The material is dense and there’s a lot of noise around the main ideas, which makes the barrier to entry even bigger for newcomers. Many times, I’ve felt like i’m too stupid to understand what StackOverflow made obvious after few researches.
Although the verbatim is complex, the ideas behind are rather simple and easy to grasp. When it “ticks”, it just becomes common sense.
It’s all about the business
Here’s the main gist : domain model should be kept separate from the dangers of the outside world, and interfaces are the bridges connecting the dots. That’s also the basis for Hexagonal Architecture, Clean Architecture, Onion Architecture, and all the other trademarked terms that more or less boil down to the same principles.
They are all domain centric.
But Domain Driven Design takes it a step further and gives the tool to structure and develop the domain itself, while the others architectures are just a mean to encapsulate the domain. In other words, you can do Hexagonal without DDD, but you can’t really do DDD without layers around.
I believe both the blue & red books are opaque about it. You’ll be tempted to believe you either go DDD or you don’t, there’s no in-between. Which is the reason I’ve been discouraged from trying DDD altogether.
But Vlad Khononov took another approach. In his book “Learning Domain-Driven Design” (affiliated link), he starts with the very basic and foundational principles of DDD, which are Subdomains, Bounded Contexts and Aggregates. He then establish a scale of usability. Depending on the task at hand, you might not need to do DDD. For once, a book that introduces DDD and isn’t all-in.
One shouldn’t use a complex tool for a trivial problem.
I loved this approach and found it more genuine and useful than the other two books. Let’s see how it unfolds.
Disclaimer
I am by no mean a DDD guru or expert, but rather a learner who condensed his knowledge inside this article. I hope to provide the kind of introduction I wish I had when I started this adventure. DDD is a complicated topic, so always double check your assumptions.
Top comments (0)