Domain-Driven Design Tackling Complexity in the Heart of Software

by Evans, Eric

• ISBN13: 9780321125217
• ISBN10: 0321125215
• Edition: 1st
• Format: Hardcover
• Copyright: 2003-08-20
• Publisher: Addison-Wesley Professional

Summary

& bull; Specific, concrete techniques that demonstrate why domain-driven design is the heart of business software & lt;br/ & gt; & bull; Key teaching points are reinforced by entertaining stories taken from real projects & lt;br/ & gt; & bull; Contains illustrative UML diagrams and supporting Java code that help the reader apply these techniques

Author Biography

Eric Evans is the founder of Domain Language

Table of Contents

Foreword	xvii
Preface	xix
Acknowledgments	xxix
Part I Putting the Domain Model to Work	1	(62)
Chapter 1: Crunching Knowledge	7	(16)
Ingredients of Effective Modeling	12	(1)
Knowledge Crunching	13	(2)
Continuous Learning	15	(2)
Knowledge-Rich Design	17	(3)
Deep Models	20	(3)
Chapter 2: Communication and the Use of Language	23	(22)
UBIQUITOUS LANGUAGE	24	(6)
Modeling Out Loud	30	(5)
One Team, One Language 32
Documents and Diagrams	35	(6)
Written Design Documents	37	(3)
Executable Bedrock	40	(1)
Explanatory Models	41	(4)
Chapter 3: Binding Model and Implementation	45	(18)
MODEL-DRIVEN DESIGN	47	(3)
Modeling Paradigms and Tool Support	50	(7)
Letting the Bones Show, Why Models Matter to Users	57	(3)
HANDS-ON MODELERS	60	(3)
Part II The Building Blocks of a Model-Driven Design	63	(124)
Chapter 4: Isolating the Domain	67	(14)
LAYERED ARCHITECTURE	68	(7)
Relating the Layers	72	(2)
Architectural Frameworks	74	(1)
The Domain Layer Is Where the Model Lives	75	(1)
THE SMART UI "ANTI-PATTERN"	76	(3)
Other Kinds of Isolation	79	(2)
Chapter 5: A Model Expressed in Software	81	(42)
Associations	82	(7)
ENTITIES (A.K.A. REFERENCE OBJECTS)	89	(8)
Modeling ENTITIES	93	(1)
Designing the Identity Operation	94	(3)
VALUE OBJECTS	97	(7)
Designing VALUE OBJECTS	99	(3)
Designing Associations That Involve VALUE OBJECTS	102	(2)
SERVICES	104	(5)
SERVICES and the Isolated Domain Layer	106	(2)
Granularity	108	(1)
Access to SERVICES	108	(1)
MODULES (A.K.A. PACKAGES)	109	(7)
Agile MODULES	111	(1)
The Pitfalls of Infrastructure-Driven Packaging	112	(4)
Modeling Paradigms	116	(7)
Why the Object Paradigm Predominates	116	(3)
Nonobjects in an Object World	119	(1)
Sticking with MODEL-DRIVEN DESIGN When Mixing Paradigms	120	(3)
Chapter 6: The Life Cycle of a Domain Object	123	(40)
AGGREGATES	125	(11)
FACTORIES	136	(11)
Choosing FACTORIES and Their Sites	139	(2)
When a Constructor Is All You Need	141	(2)
Designing the Interface	143	(1)
Where Does Invariant Logic Go?	144	(1)
ENTITY FACTORIES Versus VALUE OBJECT FACTORIES	144	(1)
Reconstituting Stored Objects	145	(2)
REPOSITORIES	147	(12)
Querying a REPOSITORY	152	(2)
Client Code Ignores REPOSITORY Implementation; Developers Do Not	154	(1)
Implementing a REPOSITORY	155	(1)
Working Within Your Frameworks	156	(1)
The Relationship with FACTORIES	157	(2)
Designing Objects for Relational Databases	159	(4)
Chapter 7: Using the Language: An Extended Example	163	(24)
Introducing the Cargo Shipping System	163	(3)
Isolating the Domain: Introducing the Applications	166	(1)
Distinguishing ENTITIES and VALUE OBJECTS	167	(2)
Role and Other Attributes	168	(1)
Designing Associations in the Shipping Domain	169	(1)
AGGREGATE Boundaries	170	(2)
Selecting REPOSITORIES	172	(1)
Walking Through Scenarios	173	(1)
Sample Application Feature: Changing the Destination of a Cargo	173	(1)
Sample Application Feature: Repeat Business	173	(1)
Object Creation	174	(3)
FACTORIES and Constructors for Cargo	174	(1)
Adding a Handling Event	175	(2)
Pause for Refactoring: An Alternative Design of the Cargo AGGREGATE	177	(2)
MODULES in the Shipping Model	179	(2)
Introducing a New Feature: Allocation Checking	181	(5)
Connecting the Two Systems	182	(1)
Enhancing the Model: Segmenting the Business	183	(2)
Performance Tuning	185	(1)
A Final Look	186	(1)
Part III Refactoring Toward Deeper Insight	187	(140)
Chapter 8: Breakthrough	193	(12)
Story of a Breakthrough	194	(7)
A Decent Model, and Yet...	194	(2)
The Breakthrough	196	(2)
A Deeper Model	198	(1)
A Sobering Decision	199	(1)
The Payoff	200	(1)
Opportunities	201	(1)
Focus on Basics	201	(1)
Epilogue: A Cascade of New Insights	202	(3)
Chapter 9: Making Implicit Concepts Explicit	205	(38)
Digging Out Concepts	206	(13)
Listen to Language	206	(4)
Scrutinize Awkwardness	210	(6)
Contemplate Contradictions	216	(1)
Read the Book	217	(2)
Try, Try Again	219	(1)
How to Model Less Obvious Kinds of Concepts	219	(24)
Explicit Constraints	220	(2)
Processes as Domain Objects	222	(2)
SPECIFICATION	224	(3)
Applying and Implementing SPECIFICATION	227	(16)
Chapter 10: Supple Design	243	(50)
INTENTION-REVEALING INTERFACES	246	(4)
SIDE-EFFECT-FREE FUNCTIONS	250	(5)
ASSERTIONS	255	(5)
CONCEPTUAL CONTOURS	260	(5)
STANDALONE CLASSES	265	(3)
CLOSURE OF OPERATIONS	268	(2)
DECLARATIVE DESIGN	270	(3)
Domain-Specific Languages	272	(1)
A Declarative Style of Design	273	(9)
Extending SPECIFICATIONS in a Declarative Style	273	(9)
Angles of Attack	282	(27)
Carve Off Subdomains	283	(1)
Draw on Established Formalisms, When You Can	283	(10)
Chapter 11: Applying Analysis Patterns	293	(16)
Chapter 12: Relating Design Patterns to the Model	309	(12)
STRATEGY (A.K.A. POLICY)	311	(4)
COMPOSITE	315	(5)
Why Not FLYWEIGHT?	320	(1)
Chapter 13: Refactoring Toward Deeper Insight	321	(6)
Initiation	321	(1)
Exploration Teams	322	(1)
Prior Art	323	(1)
A Design for Developers	324	(1)
Timing	324	(1)
Crisis as Opportunity	325	(2)
Part IV Strategic Design	327	(172)
Chapter 14: Maintaining Model Integrity	331	(66)
BOUNDED CONTEXT	335	(6)
Recognizing Splinters Within a BOUNDED CONTEXT	339	(2)
CONTINUOUS INTEGRATION	341	(3)
CONTEXT MAP	344	(8)
Testing at the CONTEXT Boundaries	351	(1)
Organizing and Documenting CONTEXT MAPS	351	(1)
Relationships Between BOUNDED CONTEXTS	352	(2)
SHARED KERNEL	354	(2)
CUSTOMER/SUPPLIER DEVELOPMENT TEAMS	356	(5)
CONFORMIST	361	(3)
ANTICORRUPTION LAYER	364	(7)
Designing the Interface of the ANTICORRUPTION LAYER	366	(1)
Implementing the ANTICORRUPTION LAYER	366	(4)
A Cautionary Tale	370	(1)
SEPARATE WAYS	371	(3)
OPEN HOST SERVICE	374	(1)
PUBLISHED LANGUAGE	375	(3)
Unifying an Elephant	378	(3)
Choosing Your Model Context Strategy	381	(8)
Team Decision or Higher	382	(1)
Putting Ourselves in Context	382	(1)
Transforming Boundaries	382	(1)
Accepting That Which We Cannot Change: Delineating the External Systems	383	(1)
Relationships with the External Systems	384	(1)
The System Under Design	385	(1)
Catering to Special Needs with Distinct Models	386	(1)
Deployment	387	(1)
The Trade-off	388	(1)
When Your Project Is Already Under Way	388	(1)
Transformations	389	(8)
Merging CONTEXTS: SEPARATE WAYS -> SHARED KERNEL	389	(2)
Merging CONTEXTS: SHARED KERNEL -> CONTINUOUS INTEGRATION	391	(2)
Phasing Out a Legacy System	393	(1)
OPEN HOST SERVICE PUBLISHED -> LANGUAGE	394	(3)
Chapter 15: Distillation	397	(42)
CORE DOMAIN	400	(4)
Choosing the CORE	402	(1)
Who Does the Work?	403	(1)
An Escalation of Distillations	404	(2)
GENERIC SUBDOMAINS	406	(9)
Generic Doesn't Mean Reusable	412	(1)
Project Risk Management	413	(2)
DOMAIN VISION STATEMENT	415	(2)
HIGHLIGHTED CORE	417	(5)
The Distillation Document	418	(1)
The Flagged CORE	419	(1)
The Distillation Document as Process Tool	420	(2)
COHESIVE MECHANISMS	422	(4)
GENERIC SUBDOMAIN Versus COHESIVE MECHANISM	424	(1)
When a MECHANISM Is Part of the CORE DOMAIN	425	(1)
Distilling to a Declarative Style	426	(2)
SEGREGATED CORE	428	(7)
The Costs of Creating a SEGREGATED CORE	429	(1)
Evolving Team Decision	430	(5)
ABSTRACT CORE	435	(1)
Deep Models Distill	436	(1)
Choosing Refactoring Targets	437	(2)
Chapter 16: Large-Scale Structure	439	(46)
EVOLVING GIRDER	444	(3)
SYSTEM METAPHOR	447	(3)
The "Naive Metaphor" and Why We Don't Need It	448	(2)
RESPONSIBILITY LAYERS	450	(15)
Choosing Appropriate Layers	460	(5)
KNOWLEDGE LEVEL	465	(10)
PLUGGABLE COMPONENT FRAMEWORK	475	(5)
How Restrictive Should a Structure Be?	480	(1)
Refactoring Toward a Fitting Structure	481	(4)
Minimalism	481	(1)
Communication and Self Discipline	482	(1)
Restructuring Yields Supple Design	482	(1)
Distillation Lightens the Load	483	(2)
Chapter 17: Bringing the Strategy Together	485	(14)
Combining Large-Scale Structures and BOUNDED CONTEXTS	485	(3)
Combining Large-Scale Structures and Distillation	488	(2)
Assessment First	490	(1)
Who Sets the Strategy?	490	(2)
Emergent Structure from Application Development	491	(1)
A Customer-Focused Architecture Team	492	(1)
Six Essentials for Strategic Design Decision Making	492	(7)
The Same Goes for the Technical Frameworks	495	(1)
Beware the Master Plan	496	(3)
Conclusion	499	(8)
Appendix: The Use of Patterns in This Book	507	(4)
Glossary	511	(4)
References	515	(2)
Photo Credits	517	(2)
Index	519

Excerpts

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 ref