Book
Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans
Summary
Eric Evans published this in 2003 to give practitioners a shared vocabulary for the modeling problems he kept encountering on enterprise projects, coining terms including ubiquitous language and bounded context that remain the field's standard reference points. The book moves from building a shared language between developers and domain experts, through binding that model to implementation, to strategic patterns for keeping a model coherent as a system grows past what one team can hold in their heads. Later chapters on distillation and large-scale structure address problems that only surface once the earlier tactical patterns are already in place. It reads less as a tutorial and more as the source text that later, friendlier introductions to DDD summarize and reorganize.
Editor's Note
For advanced readers who want to verify the origin and precise definitions of the concepts at the source. Most effective after getting the big picture from an introductory text; dense, and best used as a long-term reference than a single read.
Target Readers
- Architects who have read an introductory DDD book and now want the original definitions and reasoning behind the terms
- Engineers on enterprise projects where the domain model has grown too large for any one team to hold in their heads
- Readers willing to work through dense, example-heavy prose in exchange for the source of concepts other books summarize
Tags
Colophon
- Publisher
- 翔泳社
- ISBN
- 978-4798121963
- Published
- Apr 2011
- List price
- ¥5,720incl. taxMay differ from the actual selling price on Amazon
Get this book
* The link above is an advertisement via Amazon Associates.Related Books
Prerequisites
- Recommended
Learning Domain-Driven Design
Vlad Khononov
Reason: After mapping the strategic and tactical landscape with an introductory text, you verify the origin and precise definitions of the concepts in the source. Evans' DDD grounds the ubiquitous language and model-driven design, forming the foundation for applied judgment.
- Recommended
Clean Code
Robert C. Martin
Reason: Once you have quality standards at the code level, you point that expressiveness toward the language of the domain. Meaningful names become a ubiquitous language that bridges business and code, making the model speakable in code.
- Related
A Philosophy of Software Design, 2nd Edition
John Ousterhout
Reason: Once you have universal principles for containing complexity, you apply them specifically to the complexity of the domain. DDD tames the essential complexity inherent in the business through a model and a ubiquitous language.