Domain-Driven Design (DDD) is a software design approach that focuses on modelling software to match a domain according to input from that domain's experts. It emerged in late 90s and started to gain traction in the first decade of the 21st century. Lately many software development companies strive to implement it in their processes. But how should you as a developer get acquainted with it?
Eric Evans "Domain-Driven Design: Tackling Complexity in the Heart of Software" 2003 book is considered to be the book about DDD (also known as the blue book). However it is quite repulsive with its big price and reputation for being cumbersome to read. So how could you as a developer get a grasp of what DDD is without investing a lot of time?
You may be tempted to read the green book "Domain-Driven Design Distilled" by Vaughn Vernon. It is advertised as an accessible guide to the main principles of DDD. I fell for the trap, read it and found a lot of thing wrong with it. And I am really keen to tell about it and suggest a better alternative.
Why you should not read Domain-Driven Design Distilled
You would think that a small "distilled" version of a book about DDD should focus on creating a picture of what Domain-Driven Design is. But in fact I found myself puzzled about what it actually is after finishing this book.
The picture I got was a middle managers look on DDD: it's another practice that involves moving stickers on the wall until developers get at least some understanding of what the business wants. The book went into very little detail explaining the building blocks of a software system designed in domain-driven manner. And what it seems like no detail on how actual domain concepts should map into the software.
Instead I found myself reading multiple paragraphs on what colours and sizes your stickers should be which is bizarre to me. And there were only what felt like a few words on what aggregates and its elements are. Do not get me wrong: explaining how to employ event stormings to start using DDD is important but it should not focus on sticker colours this heavily.
Another thing in the book I found counterintuitive and unhelpful is the path it takes to explain DDD. It starts from scalability with multiple subdomains which you might not even have in your domain. And for the first 50 or so pages you see words like aggregates, events, entities that you can only guess the meaning of. I believe that those concepts are crucial in the understanding of scalability mechanisms in DDD and should always come before those.
Still the book is not useless. Perhaps if you already have some understanding of many DDD concepts and only need to bind them together this book will be largely helpful. And obviously it is good at what it really is: selling Domain-Driven Design to managers. But for practicing developers with a goal to understand how to use and implement Domain-Driven Design it is certainly a bad choice.
What you should read instead
There is actually a somewhat hidden gem in the world of books about DDD. "Domain-Driven Design Quickly" by Abel Avram and Floyd Marinescu is a free (if we are talking about the PDF/epub version) book that brilliantly summarises Eric Evans' blue book.
It follows a predictable path of explaining DDD with concrete examples which builds a real picture of a project build with DDD. It also gives the understanding of hexagonal architecture that usually comes with DDD.
To me this book felt like the actual "distilled" version of DDD. Still it only paints a picture with the theory on DDD. I felt like I still required more practical examples to really finish digesting all the information I recieved. And there is no better way to do this than to look at a real project template built with DDD and to read a few articles with different opinions and points of view on implementing DDD.
For this there is an absolutely brilliant repository by Sairyss on GitHub. domain-driven-hexagon properly implements hexagonal architecture with some of more advanced practices in TypeScript and Nest.js. Most aspects of DDD are explained in a simple language with an example in the code and links to relevant articles. Despite the fact that it is written in TypeScript you will still largely benefit from the information displayed in the repository and most likely interpret code examples well enough even if you are not familiar with JavaScript.
So if you as a developer find yourself interested in Domain-Driven Design but not invested enough to read Eric Evans' blue book you should start with "Domain-Driven Design Quickly" by Abel Avram and Floyd Marinescu and then see some practical examples in domain-driven-hexagon to really build an understanding of DDD. I hope this article saved you from investing your precious time into an unworthy book and paved a better path of getting to know DDD.
Top comments (4)
The idea of using DDD is really for large, complex software. Otherwise it could happen that you invest your time in a wrong way. After all if you just use the layered architecture correctly, you isolate the domain (what hexagonal architecture does), and you can still model your domain well even without DDD patterns.
The question here is, why do you need DDD? The idea of Vernon with the distilled book, was to create an easy and fast understanding for the IT-community. In order that managers understand the values of DDD, and inspire the developers to use it.
The point that Vernon tries to share is, you first have to adapt the environment for scaling the application (which are the strategic designs), before you start coding (or use the tactical design). So it is definitely not a coding book. You probably were just looking for something else.
I definitely appreciate the effort of Vernon, compressing the IDDD (Red Book) in a small "introduction" version.
I read DDD Distilled. Somehow for years I skipped learning about DDD.
I thought it was terrific. The hardest part by far is not being able to apply much of it because it requires a degree of organizational buy-in.
Right away It's proving useful. As the team discusses upcoming work I can describe options for modeling code that more closely resembles the business process.
I won't stop with this book. That's not its purpose. But without this condensed, faster-paced explanation I wouldn't have been motivated to pursue it further.
I have read DDD Distilled by Vernon and finds it a good summary of DDD. Not understanding the bad review in this article but appreciates to delve deeper by reading the pdf-file. Obviously the chapters about Aggregates and Domain Events are just on a high level. I have not read so many books about design (I gave up reading Eric Evans book but maybe I can read it now), part from books like Modern Software Engineering by Dave Farley (read from page 120 and skip the first part) and/or the books about TDD by Kent Beck (do the coding example and skip the last part).
This article is at the top of the Googles and promotes another book. I, like the other commenters that have used DDD, found this book very useful. There are other good books as well. But, you don't have to criticize one to promote another.
Some comments may only be visible to logged-in visitors. Sign in to view all comments.