第1页 / 共359页
第2页 / 共359页
第3页 / 共359页
第4页 / 共359页
第5页 / 共359页
第6页 / 共359页
第7页 / 共359页
第8页 / 共359页
Domain-Driven Design By Eric Evans.pdf
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
3.
4.
Pa rt II.
1.
Pa rt I.
2.
Table of Contents
Acknowledgements....................................................................................................................................6
Preface........................................................................................................................................................7
Crunching Knowledge..................................................................................................................15
Pu ttin g th e Do m a in Mode l to Work ................................ 1 2
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
Isolating the Domain.....................................................................................................................51
Bu ild ing Bloc k s o f a Mode l-Drive n De s ig n ..................... 4 9
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
Breakthrough ..............................................................................................................................136
8.
Pa rt III.
Re fa c to rin g To w a rd De e pe r In s igh t.......................... 1 3 3
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
5.
6.
7.
(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
14. Maintaining Model Integrity......................................................................................................235
St ra te g ic De s ign ........................................................ 2 3 3
Pa rt IV.
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
Epilogues................................................................................................................................................349
Pa rt V.
Co nc lu s io ns ................................................................... 3 4 9
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
years of effort, the project did produce modest, useful software, but had given up the early ambitions along
with the model focus.
Of course many things can put a project off course, bureaucracy, unclear objectives, lack of resources, to
name a few, but it is the approach to design that largely determines how complex software can become.
When complexity gets out of hand, the software can no longer be understood well enough to be easily
changed or extended. By contrast, a good design can make opportunities out of those complex features.
Some of these design factors are technological, and a great deal of effort has gone into the design of
networks, databases, and other technical dimension of software. Books have been written about how to
solve these problems. Developers have cultivated their skills.
Yet the most significant complexity of many applications is not technical. It is in the domain itself, the
activity or business of the user. When this domain complexity is not dealt with in the design, it won’t
matter that the infrastructural technology is well-conceived. A successful design must systematically deal
with this central aspect of the software.
The premise of this book is that
1. For most software projects, the primary focus should be on the domain and domain logic.
2. Complex domain designs should be based on a model.
Domain-driven design is a way of thinking and a set of priorities, aimed at accelerating software projects
that have to deal with complicated domains. To accomplish that goal, this book presents an extensive set of
design practices, techniques and principles.
Design vs. Development Process
Design books. Process books. They seldom even reference each other. Each is a complex topic in its own
right. This is a design book. But I believe that these two issues are inextricable if design concepts are to be
put into successful practice and not dry up into academic discussion. When people learn design techniques,
they feel excited by the possibilities, but then the messy realities of a real project descend on them. They
don’t see how to fit the new design ideas with the technology they must use. Or they don’t know when to
worry about a particular design aspect and when to let go in the interest of time. While it is possible to talk
with other team members about the application of a design principle in the abstract, it is more natural to
talk about the things we do together. So, while this is a design book, I’m going to barge right across that
artificial boundary when I need to. This will place design in the context of a development process.
This book is not specific to a particular methodology, but it is oriented toward the new family of “Agile
Development Processes”. Specifically, it assumes a couple of process practices are in place on the project.
These two practices are prerequisites for applying the approach in this book.
•
Iterative development. The practice of iterative development has been advocated and practiced for
decades, and is a corner stone of the Agile development methods. There are many good
discussions in the literature of Agile development and Extreme Programming, among them,
[Cockburn1998] and [Beck 1999].
• A close relationship between developers and domain experts. Domain-driven design crunches a
huge amount of knowledge into a model that reflects deep insight into the domain and a focus on
the key concepts. This is a collaboration between those who know the domain and those who
know how to build software. Because it is iterative, this collaboration must continue throughout
the project’s life.
Extreme Programming (XP), conceived by Kent Beck, Ward Cunningham and others [Beck2000], is the
most prominent of the agile processes and the one I have worked with most. To make the discussion
(Final Manuscript, April 15, 2003) © Eric Evans, 2003
8
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
