Implementing Domain-Driven Design Book Review

Agile is not easy and implementing Domain-Driven Design (DDD) is not easy. I think my favorite part of the book is that the author realizes that, and also has a realistic perspective on what it takes to successfully use agile processes and DDD. The book starts out with a really nice overview of DDD. By the time you are done the first chapter you have a pretty good high level picture of what DDD is all about. One topic he really drives home is Ubiquitous Language. Ubiquitous Language is a shared team language that defines a certain domain. When you are reading about Ubiquitous Language it may seem like something that just happens on its own. It isn't. An explicit domain language should be defined, it should not just be allowed to implicitly come about. This same concept has been around for years in Water Fall, Unified Process, RUP, and other processes. It has always been a very important part of the software development process, so don't discount it. Chapter 1 also does a great job of providing tips on how to show the business value of using DDD. The author has a clear understanding that without the support of the business you aren't going to get very far with your project, and in order to get them onboard you need to show them what they will gain by supporting DDD. The remaining chapters dig into the details of DDD. I have listed the chapters below. Their titles are pretty self-explanatory. Chapter 1. Getting Started with DDD Chapter 2. Domains, Subdomains, and Bounded Contexts Chapter 3. Context Maps Chapter 4. Architecture Chapter 5. Entities Chapter 6. Value Objects Chapter 7. Services Chapter 8. Domain Events Chapter 9. Modules Chapter 10. Aggregates Chapter 11. Factories Chapter 12. Repositories Chapter 13. Integrating Bounded Contexts Chapter 14. Application Appendix A. Aggregates and Event Sourcing: A+ES I have seen a lot of teams that could not build software with UP or RUP adopt Scrum in hopes that changing the process will make a difference. It never does. There are a variety of reasons including not doing any architecture, not having experienced developers with the right skill sets, not having the right business users involved, not having the requirements elicitation skills needed, and the list can go on and on. The author clearly understands Scrum is not a silver bullet. I mention this because DDD done correctly can give agile processes a much better chance at success, but you must have the skills on the team in order pull it off. I was really glad to see the author included a chapter on architecture. The author does a great job of covering a ton of architectural styles and patterns. Patterns, styles, and topic found in the Architecture chapter include Layers Architecture with the Dependency Inversion Principle, Hexagonal Architecture, SOA environment, REST, Data Fabric, Grid-Based Distributed Cache, and CQRS. Every chapter is an in depth look at the topic of the given chapter. I did not leave any of the chapters feeling like I missed something. I have read both Domain-Driven Design: Tackling Complexity in the Heart of Software and Patterns of Enterprise Application Architecture, and I had both handy for looking up references to them. It is not necessary to read them first, but it did help that I had. I am not going to say using DDD is easy, but I will say this book can definitely get you to where you can successfully use it. The author's writing style is really good and he is good at making the book entertaining. I will however say this, be prepared to read the entire book if you want to get to that point of successfully using DDD. There is a lot to learn, but it is worth it. I highly recommend this book to every software architect and developer. Even if you don't go all out DDD there is a ton of great advice and wisdom found in this book that will help you improve your skills.

Implementing Domain-Driven Design