Book Review: Domain Driven Design

Domain Driven Design

Author(s)

Eric Evans


My Rating

star star star star star

In 2011 my goal was to focus on improving my knowledge of the fundamentals of creating good software –  OO principles, TDD, etc – whilst spending a little less time learning about frameworks. When my colleagues invited me to join their DDD book club, it was a great opportunity to take another step towards the year’s goals.

Domain Driven Design is itself a very reputable book – as you know, because you are a developer. It’s given the internet plenty of controversy with the use of repository patterns and frameworks inspired by it. But as you’ll find out, that’s totally missing the point of DDD. In fact, that’s missing the toilet, making a foul-smelling wet patch on the bathroom floor as you stumble in after 12 pints.

Structure of the Book

The 500-page Big Blue Bible is neatly partitioned into 4 bounded contexts….I mean sections.

Part 1 – Putting the domain model to work

Down comes the groundwork in this section, as you are taught about the most basic reason for a domain model – as other projects start to falter after a few rounds of requirements and new features – yours will continue to accelerate due to being closely aligned to the problem domain.

Part 1 of the book also contains the first “wow” moment. In a cleverly selected example, Eric Evans relives the initial stages of a project where he builds the beginnings of a domain model, accompanied by a keen pair of electronics engineers. He shows how by using the ubiquitous language with constant refactorings of the model you can make great progress and learn a lot about the domain.

Part 2 – The Building Blocks of a Model-Driven Design

Part 2 of the book slips down a level into some implementation details. It contains a few sections involving repositories and N-Tier architecture that are often mistaken for full representations of DDD. But actually, the fantastic information contained in this part of the book is about isolating the domain – not letting those fancy data access frameworks or application layers pollute your work of beauty.

If you really want a concept to bake into frameworks, then maybe the aggregate root definition is something you should consider…I can’t see there would be much to go with it. Aggregates are important as they coordinate groups of objects in your domain and control their lifecycle.

Aggregates roots are also important if you plan on learning from people like Greg Young or Udi Dahan.

Part 3 – Refactoring Toward Deeper Insight

Refactoring in this context means domain refactorings – as you learn more about the domain, you change your model so it matches your understanding. Particularly important are breakthroughs, where you learn a Fuck-tonne (to quote Andy Royle, the world’s greatest developer) about the domain…. then have to make wholesale changes.

There is a “real-world-approved” example in this chapter where Eric again relives a moment from his past. This time, the dev team have found a break through in their loan payments application, but they will not meet their next deadline if they refactor. Being developers they throw two fingers to the schedule and make the changes. It all works out happy in the end, though, as the long-term payoff was superb…..and I think they kept their jobs.

Part 4 – Strategic Design

Up to this point, levels of the system of a higher granularity have only been alluded to. But part 4 introduces very important concepts like Bounded Contexts, which help to understand a domain model using a bigger picture.

Part 4 also contains other techniques for when there are multiple domain models or multiple teams e.g. shared kernel. It also shows how to integrate with legacy software using tricks like an anticorruption layer.

Part 4 of the book appears to be no less important than any of the other parts – you should definitely read it.

Conclusion

I’m not going to ruin my career and end up flipping burgers or using entity framework by not recommending this book. The only cautious words I will use are to read it carefully – and don’t think that it is enough either. You’ll need to “absorb the information by the process of osmosis over the years” as Ian Cooper puts it.

If you enjoy creating software and like to continuously delivery successful versions of an enterprise application then you’ll probably quite enjoy most parts of this book. You’ll probably enjoy the challenge of applying it to the projects you work on, too.

So I am going to further laud the much-lauded Domain Driven Design and rate it up there with the most inspiring and educational software books I have ever read.

You may also like...

Code Complete 2

Head First Design Patterns

Software Design X-Rays

My Books

Designing Autonomous Teams and Services
Patterns, Principles and Practices of Domain-Driven Design