Michal Paszkiewicz

review: Patterns, Principles, and Practices of Domain-Driven Design

When, for the 5th time in a row I couldn't find either Knuth's Art of Programming: Volume 2 or Eric Evans' Domain Driven Design in Foyles, I decided to give this book a try. Patterns, Principles, and Practices of Domain-Driven Design (PPPoDDD) has proved to be an excellent practical guide for applying DDD principles to real life.

Since I havn't read Eric Evans' DDD yet, I will not compare this book to it, even though I have a pretty good idea of what EE's book entails. The book I HAVE read on DDD is Vernon's Implementing Domain-Driven Design (IDDD). Judging by the titles, one would think that Vernon's book would prove to be the book out of the two (PPPoDDD && IDDD) that has the practical guide of how to implement DDD. However, I remember Implementing Domain-Driven Design being mostly a theory book that backs up Eric Evans' previous work, along with good arguments to use on non-technical managers to ensure that they embrace DDD. There were then some good examples and Vernon's book definitely DOES teach you how to use DDD in your team.

PPPoDDD is built on examples. Every point that is made in the book has adjoining code and diagrams. The vast multitude of patterns are explained precisely and the reader is told when to, and when not to use them. I thought this particularly useful, since many critics of DDD argue against the straw man - that you have to implement CQRS and Event Sourcing to do DDD. The authors are very clear about this not being the case, while still laying out an excellent model of how to do CQRS with Event Sourcing via Greg Young's Event Store.

Although this book took me a good few weeks to read, I was never actually bored - the writing was high quality and fascinating from front to back cover. Already being an Avid practitioner of DDD, not much of this book was new to me - although it put names to a lot of patterns I have already been using. One concept that this book definitely reinforced for me was the fact that you don't have to follow all the patterns for everything - you should always focus on the core - the sacrosanctum of your domain. I think this will help me make future decisions on project work - all too often I feel that I have given too much time to sub-domains that weren't particularly that important for a project, but I thought that spending a lot of time and making it perfect would be the way to follow DDD. I was wrong - not because it is bad to try to make everything as well as possible, but because the time could have been invested to better the core domain, which has a far greater value.

The book starts with some general principles, covering the general ideas of DDD - splitting bounded contexts, using an ubiquitous language, focusing on the bits that matter, refactoring and how to deal with a legacy big ball of mud. It then quickly moves on to some strategic patterns that cover methods of communication between bounded contexts - simple integrations, messaging and HTTP via REST. The authors follow this up with over 300 pages of tactical patterns that cover Value Objects, Entities, Domain Services, Domain Events, Aggregates, Factories, Repositories and Event Sourcing. I was impressed with the way this was done. Every pattern was introduced without a dependency on the later patterns (while mentioning them briefly in passing). This was great to see, since I have only worked on projects with most of these patterns applied at the same time. Seeing them in isolation has helped me to understand the reasoning behind each of these patterns and it has filled me with confidence that I would definitely know now when and how to implement each one separately. Finally, the book covers user interfaces and CQRS and once again, it doesn't disappoint.

Out of the big books of patterns that I have read, this has probably been one of the most enjoyable so far. The content was very well presented and I applaud the authors for this great piece of work. I cannot deny this book any less than:

*****

published: Mon Feb 27 2017

Michal Paszkiewicz's face
Michal Paszkiewicz reads books, solves equations and plays instruments whenever he isn't developing software for Transport For London. All views on this site are the author's views only and do not necessarily represent the views of TfL.