Domain-Driven Design
Tackling Complexity in the Heart of Software
Eric Evans
eric@domainlanguage.com
(415) 902-7873
(Final Manuscript, April 15, 2003)
For current draft and other information, see
www.domainlanguage.com
Copyright © 2003, Eric Evans. All rights reserved.
To Mom and Dad
(Final Manuscript, April 15, 2003) © Eric Evans, 2003
2
Table of Contents
Acknowledgements....................................................................................................................................6
Preface........................................................................................................................................................7
1.
2.
3.
P a r t I.
P u t t in g t h e Do m a in Mo d e l t o Wo r k ................................ 1 2
Crunching Knowledge ..................................................................................................................15
Communication and the Use of Language ..................................................................................24
UBIQUITOUS LANGUAGE............................................................................................................25
Documents and Diagrams .........................................................................................................31
Binding Model and Implementation............................................................................................37
MODEL-DRIVEN DESIGN............................................................................................................38
Letting the Bones Show; Why Models Matter to Users..................................................................45
HANDS-ON MODELERS ..............................................................................................................47
P a r t II.
4.
Bu ild in g Blo c k s o f a Mo d e l-Dr iv e n De s ig n ..................... 4 9
Isolating the Domain.....................................................................................................................51
LAYERED ARCHITECTURE..........................................................................................................52
The Domain Layer is Where the Model Lives ..........................................................................56
SMART UI ANTI-PATTERN .........................................................................................................57
A Model Expressed in Software...................................................................................................60
Associations ..............................................................................................................................61
ENTITIES (AKA REFERENCE OBJECTS)........................................................................................65
VALUE OBJECTS.........................................................................................................................70
SERVICES ...................................................................................................................................75
MODULES (AKA PACKAGES) ......................................................................................................79
Modeling Paradigms .......................................................................................................................84
The Lifecycle of a Domain Object ...............................................................................................88
AGGREGATES.............................................................................................................................89
FACTORIES.................................................................................................................................98
REPOSITORIES ..........................................................................................................................106
Designing Objects for Relational Databases ...........................................................................113
Using the Language in an Example: A Cargo Shipping System.............................................115
5.
6.
7.
P a r t III.
Re fa c t o r in g To w a rd De e p e r In s ig h t .......................... 1 3 3
8.
Breakthrough ..............................................................................................................................136
9. Making Implicit Concepts Explicit............................................................................................145
Listen to Language..................................................................................................................145
Scrutinize Awkwardness.........................................................................................................148
Contemplate Contradictions....................................................................................................152
Read the Book.........................................................................................................................153
Try, Try Again ........................................................................................................................154
Expressing Less Obvious Categories of Concepts........................................................................155
Explicit Constraints.................................................................................................................155
Representing Processes as Domain Objects............................................................................157
SPECIFICATION.........................................................................................................................158
10. Supple Design ..............................................................................................................................170
INTENTION REVEALING INTERFACES .......................................................................................172
SIDE-EFFECT-FREE FUNCTIONS ...............................................................................................175
ASSERTIONS.............................................................................................................................179
CONCEPTUAL CONTOURS.........................................................................................................183
STANDALONE CLASSES............................................................................................................188
CLOSURE OF OPERATIONS........................................................................................................190
(Final Manuscript, April 15, 2003) © Eric Evans, 2003
3
Declarative Design ..................................................................................................................192
Extending SPECIFICATIONS in a Declarative Style ..................................................................193
Carve off Subdomains...................................................................................................................200
Draw on Established Formalisms, When You Can.......................................................................200
Example Integrating the Patterns: Shares Math ............................................................................200
11. Applying Analysis Patterns........................................................................................................207
12. Relating Design Patterns to the Model......................................................................................218
STRATEGY AKA POLICY ...........................................................................................................219
COMPOSITE ..............................................................................................................................223
Why Not FLYWEIGHT?..................................................................................................................229
13. Bringing the Pieces Together .....................................................................................................230
P a r t IV.
S t r a t e g ic De s ig n ........................................................ 2 3 3
14. Maintaining Model Integrity......................................................................................................235
BOUNDED CONTEXT ................................................................................................................238
CONTINUOUS INTEGRATION.....................................................................................................242
CONTEXT MAP.........................................................................................................................244
Relationships Between BOUNDED CONTEXTS...............................................................................250
SHARED KERNEL......................................................................................................................251
CUSTOMER/SUPPLIER DEVELOPMENT TEAMS............................................................................252
CONFORMIST............................................................................................................................255
ANTICORRUPTION LAYER ........................................................................................................257
SEPARATE WAYS .....................................................................................................................261
OPEN HOST SERVICE................................................................................................................263
PUBLISHED LANGUAGE............................................................................................................264
Unifying an Elephant ....................................................................................................................266
Choosing Your Model Context Strategy.......................................................................................268
Transformations ............................................................................................................................273
SHARED KERNEL) .................................................274
Merging CONTEXTS (SEPARATE WAYS
CONTINUOUS INTEGRATION).................................276
Merging CONTEXTS (SHARED KERNEL
Phasing Out a Legacy System.................................................................................................277
PUBLISHED LANGUAGE .....................................................................278
OPEN HOST SERVICE
15. Distillation....................................................................................................................................279
CORE DOMAIN .........................................................................................................................281
GENERIC SUBDOMAINS ............................................................................................................285
DOMAIN VISION STATEMENT...................................................................................................290
HIGHLIGHTED CORE.................................................................................................................292
COHESIVE MECHANISMS..........................................................................................................295
Distilling to a Declarative Style ..............................................................................................297
SEGREGATED CORE..................................................................................................................298
ABSTRACT CORE......................................................................................................................305
Deep Models Distill ......................................................................................................................306
Choosing Refactoring Targets.......................................................................................................306
16. Large-Scale Structure.................................................................................................................307
EVOLVING ORDER....................................................................................................................310
SYSTEM METAPHOR.................................................................................................................312
RESPONSIBILITY LAYERS .........................................................................................................314
KNOWLEDGE LEVEL ................................................................................................................326
PLUGGABLE COMPONENT FRAMEWORK ..................................................................................333
How Restrictive Should a Structure Be?.......................................................................................336
Refactoring Toward a Fitting Structure ........................................................................................337
17. Bringing the Strategy Together .................................................................................................339
Bringing Together Large-Scale Structures and BOUNDED CONTEXTS ..........................................339
(Final Manuscript, April 15, 2003) © Eric Evans, 2003
4
Bringing Together Large-Scale Structures and Distillation ..........................................................342
Assessment First ...........................................................................................................................343
Who Sets the Strategy...................................................................................................................344
P a r t V.
Co n c lu s io n s ................................................................... 3 4 9
Epilogues................................................................................................................................................349
Looking Forward...................................................................................................................................352
Glossary..................................................................................................................................................353
References ..............................................................................................................................................356
Appendix: Use of Patterns in This Book .............................................................................................358
PATTERN NAME .......................................................................................................................359
(Final Manuscript, April 15, 2003) © Eric Evans, 2003
5
Acknowledgements
I have been working on this book, in one form or another, for over four years, and many people have
helped and supported me along the way.
I thank the many people who have read manuscripts and commented. This book would simply not have
been possible without that feedback. A few have given their reviews especially generous attention. The
Silicon Valley Patterns Group, led by Russ Rufer and Tracy Bialek, spent seven weeks scrutinizing the first
complete draft of the book. The University of Illinois reading group led by Ralph Johnson also spent
several weeks scrutinizing a later draft. Listening to the long, lively discussions of these groups had a
profound effect. Kyle Brown and Martin Fowler contributed detailed feedback, valuable insights and
invaluable moral support (while sitting on a fish). Ward Cunningham’s feedback was important. Alistair
Cockburn encouraged me and helped me find my way through the publication process. David Siegel and
Eugene Wallingford have helped me avoid embarrassing myself in the more technical parts. Vibhu
Mohindra and Vladimir Gitlevitch painstakingly checked all the code examples.
Rob Mee read some of my earliest explorations of the material, and brainstormed ideas with me when I was
groping for some way to communicate this style of design. He then poured over a much later draft with me.
Josh Kerievsky is responsible for one of the major turning points in the book’s development: He persuaded
me to try out the “Alexandrian” pattern format, which became the backbone of the book’s organization. He
also helped me to bring some of the material now in Part II together into a coherent form for the first time,
during the intensive “shepherding” process preceding the PLoP conference in 1999. This became a seed
around which the much of the rest of the book formed.
Before I could have conceived of this book, I had to form my view and understanding of software
development. That development owed a lot to the generosity of a few brilliant people who acted as
informal mentors to me, as well as friends. David Siegel, Eric Gold, and Iseult White, in very different
ways, helped me form my way of thinking about software design. At more or less the same time, Bruce
Gordon, Richard Freyberg, and Judith Segal, also in very different ways, helped me find my way in the
world of successful project work.
There was also a body of ideas in the air at the crucial time that formed the basis of my own technical view.
Some of those contributions will be clear in the main text and referenced where possible. Others are so
fundamental that I don’t even realize their influence on me.
My master’s thesis advisor, Dr. Bala Subramanium, turned me on to mathematical modeling, which we
applied to chemical reaction kinetics, but modeling is modeling, and that work was part of the path that led
to this book.
And even before that, my way of thinking was formed thanks to my parents, Carol and Gary Evans, and a
few special teachers, especially Dale Courier (a high school math teacher), Mary Brown (a high school
English composition teacher), and a 6th grade science teacher whose name I have shamefully forgotten.
Finally, I thank my friends and family, and Fernando De Leon, for their encouragement throughout this
long process.
(Final Manuscript, April 15, 2003) © Eric Evans, 2003
6
Preface
Leading software designers have recognized domain modeling and design as critical topics for at least
twenty years, yet surprisingly little has been written about what needs to be done or how to do it. Although
it has never been clearly formulated, a philosophy has developed as an undercurrent in the object
community, which I call “domain-driven design”.
I have spent the past decade focused on developing complex systems in several business and technical
domains. I’ve tried best practices in design and development process as they have emerged from the leaders
in the object-oriented development community. Some of my projects were very successful; a few failed. A
feature common to the successes was a rich domain model that evolved through iterations of design and
became part of the fabric of the project.
This book provides a framework for making design decisions and a technical vocabulary for discussing
domain design. It is a synthesis of widely accepted best practices along with my own insights and
experiences. Projects facing complex domains can use this framework to approach domain-driven design
systematically.
Contrasting Three Projects
Three projects stand out in my memory as vivid examples of the dramatic effect domain design practice has
on development results. Although all three delivered useful software, only one achieved its ambitious
objectives and delivered complex software that continued to evolve to meet ongoing needs of the
organization.
I watched one project get out of the gate fast with a useful, simple web-based trading system. Developers
were flying by the seat of their pants, but simple software can be written with little attention to design. As a
result of this initial success, expectations for future development were sky-high. It was at this point that I
was approached to work on the second version. When I took a close look, I saw that they lacked a domain
model, or even a common language on the project, and were saddled with an unstructured design. So when
the project leaders did not agree with my assessment, I declined the job. A year later, they found
themselves bogged down and unable to deliver a second version. Although their use of technology was not
exemplary, it was the business logic that overcame them. Their first release had ossified prematurely into a
high-maintenance legacy.
Lifting this ceiling on complexity calls for a more serious approach to the design of domain logic. Early in
my career, I was fortunate to end up on a project that did emphasize domain design. This project, in a
domain at least as complex as the one above, also started with a modest initial success, delivering a simple
application for institutional traders. But this delivery was followed up with successive accelerations of
development. Each successive iteration opened exciting new options for integration and elaboration of
functionality. The team way able to respond to the needs of the traders with flexibility and expanding
capability. This upward trajectory was directly attributable to an incisive domain model, repeatedly refined
and expressed in code. As the team gained new insight into the domain, the model deepened. The quality of
communication improved among developers and between developers and domain experts, and the design,
far from imposing an ever-heavier maintenance burden, became easier to modify and extend.
Unfortunately, not all projects that start with this intention manage to arrive at this virtuous cycle. One
project I joined started with lofty aspirations to build a global enterprise system based on a domain model,
but finally had a disappointing result. The team had good tools, a good understanding of the business and
gave serious attention to modeling. But a separation of developer roles led to a disconnect between the
model and implementation, so the design did not reflect the deep analysis that was going on. In any case,
the design of detailed business objects was not rigorous enough to support combining them in elaborate
applications. Repeated iteration produced no improvement in the code, due to uneven skill-level among
developers with no clear understanding of the particular kind of rigor needed. As months rolled by,
development work became mired in complexity and the team lost its cohesive vision of the system. After
(Final Manuscript, April 15, 2003) © Eric Evans, 2003
7