I write this article as a student of Domain Driven Design, and welcome comments from experience DDD practioners.

When I’m on holiday I usually take something fairly brain dead with me to read, such as a Lee Child book. So I felt a bit eccentric reading this on the sun lounger while everyone else read their paperback. But this is a book that requires a decent amount of time set aside for reading.

I bought it more than a year ago, at the same time as Code Complete. Although Domain Driven Design is a shorter book, it is a slower read, and generally aimed at a more sophisticated audience. To summarize, Code complete is a book for anyone aiming to be a good developer, whereas Domain Driven Design is a book for good developers wanting to walk the path towards becoming a great developer.

Enterprise Integration Patterns

Forgive me for this little detour, and feel free to skip to the next section if you wish. Domain Driven Design reminded me of another Addison-Wesley book I read called Enterprise Integration Patterns, a book which excited me about enterprise architecture. I had written my own little message queuing application, but this provided much more information about the possibilities.

If this subject is of interest to you I recommend reading a free chapter:
Bond Trading Case Study

However, about a year after reading Enterprise Integration Patterns, I had become a little dis-illusioned about enterprise architecture.

The software I wrote remained in use but for further systems integration the company had spent a lot of money on a much more powerful system call BizTalk. Because of its complexity, rather than treating it as a pattern, it was considered an application in its own right and was owned by a particular development team. Whenever there was any configuration required, it would require at the very minimum a conversation with the development team that owned BizTalk. So it never completely achieved the goal of divorcing development team’s dependency on each other. Moreover, this was a lot of effort on work that was at only tangential to the actual needs of the business.

So it was nice to find Domain Driven Design is firmly focused on the needs of the business domain.

Who should buy Domain Driven Design?

Anyone who wants to become, or already is an enterprise architect.
Senior developers who are interested in more sophisticated architecture.

How should I read it?

If you just want to get a quick overview of the topic, the best part to read is the conclusion at the end of the book. The following quote should shed a little light, and the full conclusion more so.

No project will ever employ every technique in this book. Even so, any project committed to domain-driven design will be recognizable in a few ways. The defining characteristic is a priority on understanding the target domain and incorparating that understanding into the software. Everything else flows from that premise.

You will need to read the whole book to understand all the aspects however, and even then you will still only be at the beginning of your journey into Domain Driven Design. There is another book by Vaughn Vernon (which I haven’t yet read) called Implementing Domain Driven Design which builds on this foundational book. You need to put theory into practice in a way that makes sense for your business.

DDD Book Contents

Part I – Putting the Domain Model to Work
Chapter 1: Crunching Knowledge
Chapter 2: Communication and the Use of Language
Chapter 3: Binding Model and Implementation

Part II – The Building Blocks of a Model #-Driven Design
Chapter 4: Isolating the Domain
Chapter 5: A Model Expressed in Software
Chapter 6: The Life Cycle of a Domain Object
Chapter 7: Using the Language: An Extended Example

Part III – Refactoring Toward Deeper Insight
Chapter 8: Breakthrough
Chapter 9: Making Implicit Concepts Explicit
Chapter 10: Supple Design
Chapter 11: Applying Analysis Patterns
Chapter 12: Relating Design Patterns to the Model
Chapter 13: Refactoring Toward Deeper Insight

Part IV – Strategic Design
Chapter 14: Maintaining Model Integrity
Chapter 15: Distillation
Chapter 16: Large-Scale Structure
Chapter 17: Bringing the Strategy Together
Conclusion

If you prefer watching videos

There are a couple of courses on Domain Driven Design that should be of interest to you if you have a pluralsight subscription.

Domain Driven Design Fundamentals – By Julie Lerman and Steve Smith and including a cameo appearance by Eric Evans himself. I found this course quite a bit quicker to watch and easier to understand than the book. However the course does not cover all of the content in the book. Think of this course as an introduction, with the book providing a lot of further information.

Modern Software Architecture: Domain Models, CQRS, and Event Sourcing – By Dino Esposito. I am currently partway through this course and enjoying it. It includes misconceptions about DDD, and lessons learned in the field after the book was published.

If you are interested in what Eric Evans has learned since he wrote the book watch this talk.

I would say Esposito’s course is a bit more advanced than the Fundamentals course, it can be watched and understood without having read the book or watching DDD Fundamentals first, although my recommendation is to watch the other course first.