This post is a book review of Eric Evans’ Domain Driven Design.
I recently put together a video review of Eric Evan’s Domain Driven Design on YouTube. I wanted to put together a written summary to share some additional thoughts.
First things first, what is Domain Driven Design about?
In one sentence, Domain Driven Design is a book about how to design systems right the first time, or at least try. It focuses on the use of Domain Modeling to guide the rules and understanding of a domain’s space. Eric Evans shares some of the hidden gems about software architecture, system design, design patterns, and much more in this 500 and some page book behemoth of a book.
Software design and architecture are one of those unfortunate things where you often figure out the right way of doing things after you’ve already done it. Its unfortunate, too, since software that is already established often a) is more difficult to change, and b) harder to get business justification to go and revisit. Things always look better in a rear-view mirror…
Enough digression, lets talk more about this book. I’m going separate the remainder of this post in 3 sections: 1) The Good, 2) The Bad, 3) Summary. Feel free to skip down to the respective sections.
The Good
Domain Driven Design is an excellent book by most accounts. In essence, it is a book that draws on the experience of Eric Evans, a software architect with over two decades of experience building large scale systems. Evans does a great job of sharing some of the examples he has seen in the real world, and applies them to certain sections of the book. This approach allows the content to be realistic and relatable. Also, there’s always something fascinating about seeing other real-world problems others have solved.
Although Evans draws from a multitude of experiences, he tends to focus on a single Logistics and Freight Shipping example throughout the book. Woohoo for me! (I love logistics). The neat part here is that as he progresses throughout different sections of the book, he always falls back to the same example to demonstrate how the newly introduced concept applies. Over the course of the book, you really get to see how the architecture of this application evolves from something primitive, to something sophisticated and extensible.
One of my favourite parts of this book was Evans’ introduction of three key concepts: Entity Objects, Value Objects and Aggregates. Evans goes into some detail into how any data object you deal with can be categorized into one of the three categories. Evans also introduces a concept he terms Bounded Countexts that push the architect to draw conceptual boundaries across domains and group entities and behaviours into them.
The Bad
Nothings perfect, and neither is this book.
This book introduces some great ideas, but often you need to rummage through redundant verb-age and thick language. Personally, I enjoy reading before I go to bed; unfortunately for me, this book reads more like a college textbook. I appreciate the ideas Evans brings forth in this great book, but I couldn’t help but think ‘can’t he just cut to the chase?’ way too often.
Summary
In summary, Domain Driven Design provides real and practical tips to build your system as ‘right’ as possible the first time. It is an essential read for software developers beginner and veteran alike.
My key takeaways are as follows:
- Entities Objects have an ID and are trackable through time, Value Objects do not
- Really talk out your system and use cases with Product Managers, Engineers, Managers, and others to develop your Ubiquitous Language
- Ubiquitous Language evolves over time. Don’t be afraid to revisit your models and refactor when better fitting models are discovered
- Carve out the responsibility of your system, preferably using a Service Oriented Architecture (SOA) in large scale systems
Further Reading