This will be my first book review on my blog. I have been wanting to write this review for some time now. The reason I’m writing this review is to have something to reference back to in the future, and to share with you what I learned. I hope that if you have read this book you would comment on what you have learned.
The reason I read Domain-Driven Design: Tackling Complexity in the Heart of Software was because DDD is always a topic that I hear about. I just had to read the book to get a better understanding of the subject. Reading this book was a real pleasure, and I would encourage everyone wanting to improve their design and business knowledge to read it.
This book is broken into four parts. These parts are Putting the Domain Model to Work, The Building Blocks of a Model-Driven Design, Refactoring Toward Deeper Insight and Strategic Design. In the paragraphs below I will talk about what I learned from each.
I think that the first part of the book was about understanding how to model out the domain in which you are working. To do this you would use an ubiquitous language. This language is what is used by the developers and domain experts to talk about the different parts of the domain. Also as time evolves, knowledge of the domain is distilled. This knowledge grows by teams practicing continuous learning. This comes by improving technical knowledge and understanding general domain-modeling skills.
This part talks about the building blocks. The book defines the follow blocks:
- Association – The interaction between modeling and implementation is particularly tricky with the associations between objects
- Entities – Many objects are not fundamentally defined by the their attributes, but rather by a thread of continuity and identity.
- Value Objects – Many objects have no conceptual identity. These objects describe some characteristic of a thing.
- Services – In some cases, the clearest and most pragmatic design includes operations that do not conceptually belong to any object. Rather than forces the issue, we can follow the natural contours of the problem space and include SERVICES explicitly in the model.
- Modules – The MODELS in the domain layer should emerge as a meaningful part of the model, telling the story of the domain on a larger scale.
- Aggregate – An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data change. Each AGGREGATE has a root and a boundary.
- Factories – When creation of an object, or a entire AGGREGATE, becomes complicated or reveals too much of the internal structure, FACTORIES provide encapsulation.
- Repositories – Associations allow us to find an object based on its relationship to another. But we must have a starting point for a traversal to an ENTITY or VALUE in the middle of its life cycle.
Refactoring was talked about in this section of the book. The book defined refactoring as the redesign of software in ways that do not change its functionality. Part of this process is to refactor to design patterns. Also as you again better insight to the model, you make changes to improve the quality of the design.
The last part of the book talks about Strategic Design. This section helped me understand how different systems would fit together. The themes that were talked about are context, distillation and large-scale structure. Context is about how to define the separation of the domain parts, because sometimes it may not be a good idea to put all the pieces together. Distillation is the process of bringing clarity to a large model. Lastly, large-scale structure talks about the complete picture.
In conclusion, I would say if you are interested in Domain Driven Design then I would read this book. If you have any questions or comments, please post a comment to this blog post.