Domain-Driven Design Read online

  Domain-Driven Design

  Tackling Complexity in the Heart of Software

  Eric Evans

  Upper Saddle River, NJ • Boston • Indianapolis • San Francisco

  New York • Toronto • Montreal • London • Munich • Paris • Madrid

  Capetown • Sydney • Tokyo • Singapore • Mexico City

  Many of the designations used by manufacturers and sellers to distinguish their products are claimed as trademarks. Where those designations appear in this book, and Addison-Wesley was aware of a trademark claim, the designations have been printed with initial capital letters or in all capitals.

  The author and publisher have taken care in the preparation of this book, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for incidental or consequential damages in connection with or arising out of the use of the information or programs contained herein.

  See page 517 for photo credits.

  The publisher offers discounts on this book when ordered in quantity for bulk purchases and special sales. For more information, please contact:

  U.S. Corporate and Government Sales

  (800) 382-3419

  [email protected]

  For sales outside of the U.S., please contact:

  International Sales

  [email protected]

  Visit Addison-Wesley on the Web: www.awprofessional.com

  Library of Congress Cataloging-in-Publication Data

  Evans, Eric, 1962–

  Domain-driven design : tackling complexity in the heart of software / Eric

  Evans.

  p. cm.

  Includes bibliographical references and index.

  ISBN 0-321-12521-5

  1. Computer software—Development. 2. Object-oriented programming

  (Computer science) I. Title.

  QA76.76.D47E82 2003

  005.1—dc21

  2003050331

  Copyright © 2004 by Eric Evans

  All rights reserved. No part of this publication may be reproduced, stored in a retrieval system, or transmitted, in any form, or by any means, electronic, mechanical, photocopying, recording, or otherwise, without the prior consent of the publisher. Printed in the United States of America. Published simultaneously in Canada.

  For information on obtaining permission for use of material from this work, please submit a written request to:

  Pearson Education, Inc.

  Rights and Contracts Department

  500 Boylston Street, Suite 900

  Boston, MA 02116

  Fax: (617) 671-3447

  ISBN 0-321-12521-5

  Text printed in the United States on recycled paper at Courier in Westford,

  Massachusetts.

  Twenty-First printing, July 2015

  Praise for Domain-Driven Design

  “This book belongs on the shelf of every thoughtful software developer.”

  —Kent Beck

  “Eric Evans has written a fantastic book on how you can make the design of your software match your mental model of the problem domain you are addressing.

  “His book is very compatible with XP. It is not about drawing pictures of a domain; it is about how you think of it, the language you use to talk about it, and how you organize your software to reflect your improving understanding of it. Eric thinks that learning about your problem domain is as likely to happen at the end of your project as at the beginning, and so refactoring is a big part of his technique.

  “The book is a fun read. Eric has lots of interesting stories, and he has a way with words. I see this book as essential reading for software developers—it is a future classic.”

  —Ralph Johnson, author of Design Patterns

  “If you don’t think you are getting value from your investment in object-oriented programming, this book will tell you what you’ve forgotten to do.”

  —Ward Cunningham

  “What Eric has managed to capture is a part of the design process that experienced object designers have always used, but that we have been singularly unsuccessful as a group in conveying to the rest of the industry. We’ve given away bits and pieces of this knowledge . . . but we’ve never organized and systematized the principles of building domain logic. This book is important.”

  —Kyle Brown, author of Enterprise Java Programming with IBM WebSphere

  “Eric Evans convincingly argues for the importance of domain modeling as the central focus of development and provides a solid framework and set of techniques for accomplishing it. This is timeless wisdom, and will hold up long after the methodologies du jour have gone out of fashion.”

  —Dave Collins, author of Designing Object-Oriented User Interfaces

  “Eric weaves real-world experience modeling—and building—business applications into a practical, useful book. Written from the perspective of a trusted practitioner, Eric’s descriptions of ubiquitous language, the benefits of sharing models with users, object life-cycle management, logical and physical application structuring, and the process and results of deep refactoring are major contributions to our field.”

  —Luke Hohmann, author of Beyond Software Architecture

  To Mom and Dad

  Contents

  Foreword

  Preface

  Acknowledgments

  Part I Putting the Domain Model to Work

  Chapter 1: Crunching Knowledge

  Ingredients of Effective Modeling

  Knowledge Crunching

  Continuous Learning

  Knowledge-Rich Design

  Deep Models

  Chapter 2: Communication and the Use of Language

  UBIQUITOUS LANGUAGE

  Modeling Out Loud

  One Team, One Language

  Documents and Diagrams

  Written Design Documents

  Executable Bedrock

  Explanatory Models

  Chapter 3: Binding Model and Implementation

  MODEL-DRIVEN DESIGN

  Modeling Paradigms and Tool Support

  Letting the Bones Show: Why Models Matter to Users

  HANDS-ON MODELERS

  Part II The Building Blocks of a Model-Driven Design

  Chapter 4: Isolating the Domain

  LAYERED ARCHITECTURE

  Relating the Layers

  Architectural Frameworks

  The Domain Layer Is Where the Model Lives

  THE SMART UI “ANTI-PATTERN”

  Other Kinds of Isolation

  Chapter 5: A Model Expressed in Software

  Associations

  ENTITIES (A.K.A. REFERENCE OBJECTS)

  Modeling ENTITIES

  Designing the Identity Operation

  VALUE OBJECTS

  Designing VALUE OBJECTS

  Designing Associations That Involve VALUE OBJECTS

  SERVICES

  SERVICES and the Isolated Domain Layer

  Granularity

  Access to SERVICES

  MODULES (A.K.A. PACKAGES)

  Agile MODULES

  The Pitfalls of Infrastructure-Driven Packaging

  Modeling Paradigms

  Why the Object Paradigm Predominates

  Nonobjects in an Object World

  Sticking with MODEL-DRIVEN DESIGN When Mixing Paradigms

  Chapter 6: The Life Cycle of a Domain Object

  AGGREGATES

  FACTORIES

  Choosing FACTORIES and Their Sites

  When a Constructor Is All You Need

  Designing the Interface

  Where Does Invariant Logic Go?

  ENTITY FACTORIES Versus VALUE OBJECT FACTORIES

  Reconstituting Stored Objects
/>
  REPOSITORIES

  Querying a REPOSITORY

  Client Code Ignores REPOSITORY Implementation; Developers Do Not

  Implementing a REPOSITORY

  Working Within Your Frameworks

  The Relationship with FACTORIES

  Designing Objects for Relational Databases

  Chapter 7: Using the Language: An Extended Example

  Introducing the Cargo Shipping System

  Isolating the Domain: Introducing the Applications

  Distinguishing ENTITIES and VALUE OBJECTS

  Role and Other Attributes

  Designing Associations in the Shipping Domain

  AGGREGATE Boundaries

  Selecting REPOSITORIES

  Walking Through Scenarios

  Sample Application Feature: Changing the Destination of a Cargo

  Sample Application Feature: Repeat Business

  Object Creation

  FACTORIES and Constructors for Cargo

  Adding a Handling Event

  Pause for Refactoring: An Alternative Design of the Cargo AGGREGATE

  MODULES in the Shipping Model

  Introducing a New Feature: Allocation Checking

  Connecting the Two Systems

  Enhancing the Model: Segmenting the Business

  Performance Tuning

  A Final Look

  Part III Refactoring Toward Deeper Insight

  Chapter 8: Breakthrough

  Story of a Breakthrough

  A Decent Model, and Yet . . .

  The Breakthrough

  A Deeper Model

  A Sobering Decision

  The Payoff

  Opportunities

  Focus on Basics

  Epilogue: A Cascade of New Insights

  Chapter 9: Making Implicit Concepts Explicit

  Digging Out Concepts

  Listen to Language

  Scrutinize Awkwardness

  Contemplate Contradictions

  Read the Book

  Try, Try Again

  How to Model Less Obvious Kinds of Concepts

  Explicit Constraints

  Processes as Domain Objects

  SPECIFICATION

  Applying and Implementing SPECIFICATION

  Chapter 10: Supple Design

  INTENTION-REVEALING INTERFACES

  SIDE-EFFECT-FREE FUNCTIONS

  ASSERTIONS

  CONCEPTUAL CONTOURS

  STANDALONE CLASSES

  CLOSURE OF OPERATIONS

  Declarative Design

  Domain-Specific Languages

  A Declarative Style of Design

  Extending SPECIFICATIONS in a Declarative Style

  Angles of Attack

  Carve Off Subdomains

  Draw on Established Formalisms, When You Can

  Chapter 11: Applying Analysis Patterns

  Chapter 12: Relating Design Patterns to the Model

  STRATEGY (A.K.A. POLICY)

  COMPOSITE

  Why Not FLYWEIGHT?

  Chapter 13: Refactoring Toward Deeper Insight

  Initiation

  Exploration Teams

  Prior Art

  A Design for Developers

  Timing

  Crisis as Opportunity

  Part IV Strategic Design

  Chapter 14: Maintaining Model Integrity

  BOUNDED CONTEXT

  Recognizing Splinters Within a BOUNDED CONTEXT

  CONTINUOUS INTEGRATION

  CONTEXT MAP

  Testing at the CONTEXT Boundaries

  Organizing and Documenting CONTEXT MAPS

  Relationships Between BOUNDED CONTEXTS

  SHARED KERNEL

  CUSTOMER/SUPPLIER DEVELOPMENT TEAMS

  CONFORMIST

  ANTICORRUPTION LAYER

  Designing the Interface of the ANTICORRUPTION LAYER

  Implementing the ANTICORRUPTION LAYER

  A Cautionary Tale

  SEPARATE WAYS

  OPEN HOST SERVICE

  PUBLISHED LANGUAGE

  Unifying an Elephant

  Choosing Your Model Context Strategy

  Team Decision or Higher

  Putting Ourselves in Context

  Transforming Boundaries

  Accepting That Which We Cannot Change: Delineating the External Systems

  Relationships with the External Systems

  The System Under Design

  Catering to Special Needs with Distinct Models

  Deployment

  The Trade-off

  When Your Project Is Already Under Way

  Transformations

  Merging CONTEXTS: SEPARATE WAYS → SHARED KERNEL

  Merging CONTEXTS: SHARED KERNEL → CONTINUOUS INTEGRATION

  Phasing Out a Legacy System

  OPEN HOST SERVICE → PUBLISHED LANGUAGE

  Chapter 15: Distillation

  CORE DOMAIN

  Choosing the CORE

  Who Does the Work?

  An Escalation of Distillations

  GENERIC SUBDOMAINS

  Generic Doesn’t Mean Reusable

  Project Risk Management

  DOMAIN VISION STATEMENT

  HIGHLIGHTED CORE

  The Distillation Document

  The Flagged CORE

  The Distillation Document as Process Tool

  COHESIVE MECHANISMS

  GENERIC SUBDOMAIN Versus COHESIVE MECHANISM

  When a MECHANISM Is Part of the CORE DOMAIN

  Distilling to a Declarative Style

  SEGREGATED CORE

  The Costs of Creating a SEGREGATED CORE

  Evolving Team Decision

  ABSTRACT CORE

  Deep Models Distill

  Choosing Refactoring Targets

  Chapter 16: Large-Scale Structure

  EVOLVING ORDER

  SYSTEM METAPHOR

  The “Naive Metaphor” and Why We Don’t Need It

  RESPONSIBILITY LAYERS

  Choosing Appropriate Layers

  KNOWLEDGE LEVEL

  PLUGGABLE COMPONENT FRAMEWORK

  How Restrictive Should a Structure Be?

  Refactoring Toward a Fitting Structure

  Minimalism

  Communication and Self-Discipline

  Restructuring Yields Supple Design

  Distillation Lightens the Load

  Chapter 17: Bringing the Strategy Together

  Combining Large-Scale Structures and BOUNDED CONTEXTS

  Combining Large-Scale Structures and Distillation

  Assessment First

  Who Sets the Strategy?

  Emergent Structure from Application Development

  A Customer-Focused Architecture Team

  Six Essentials for Strategic Design Decision Making

  The Same Goes for the Technical Frameworks

  Beware the Master Plan

  Conclusion

  Appendix: The Use of Patterns in This Book

  Glossary

  References

  Photo Credits

  Index

  Foreword

  There are many things that make software development complex. But the heart of this complexity is the essential intricacy of the problem domain itself. If you’re trying to add automation to complicated human enterprise, then your software cannot dodge this complexity—all it can do is control it.

  The key to controlling complexity is a good domain model, a model that goes beyond a surface vision of a domain by introducing an underlying structure, which gives the software developers the leverage they need. A good domain model can be incredibly valuable, but it’s not something that’s easy to make. Few people can do it well, and it’s very hard to teach.

  Eric Evans is one of those few who can create domain models well. I discovered this by working with him—one of those wonderful times when you find a client who’s more skilled than you are. Our collaboration was short but enormous fun. Since then we’ve stayed in touch, and I’ve watched this book gestate slowly.

&n
bsp; It’s been well worth the wait.

  This book has evolved into one that satisfies a huge ambition: To describe and build a vocabulary about the very art of domain modeling. To provide a frame of reference through which we can explain this activity as well as teach this hard-to-learn skill. It’s a book that’s given me many new ideas as it has taken shape, and I’d be astonished if even old hands at conceptual modeling don’t get a raft of new ideas from reading this book.

  Eric also cements many of the things that we’ve learned over the years. First, in domain modeling, you shouldn’t separate the concepts from the implementation. An effective domain modeler can not only use a whiteboard with an accountant, but also write Java with a programmer. Partly this is true because you cannot build a useful conceptual model without considering implementation issues. But the primary reason why concepts and implementation belong together is this: The greatest value of a domain model is that it provides a ubiquitous language that ties domain experts and technologists together.

  Another lesson you’ll learn from this book is that domain models aren’t first modeled and then implemented. Like many people, I’ve come to reject the phased thinking of “design, then build.” But the lesson of Eric’s experience is that the really powerful domain models evolve over time, and even the most experienced modelers find that they gain their best ideas after the initial releases of a system.

  I think, and hope, that this will be an enormously influential book. One that will add structure and cohesion to a very slippery field while it teaches a lot of people how to use a valuable tool. Domain models can have big consequences in controlling software development—in whatever language or environment they are implemented.

  One final yet important thought. One of things I most respect about this book is that Eric is not afraid to talk about the times when he hasn’t been successful. Most authors like to maintain an air of disinterested omnipotence. Eric makes it clear that like most of us, he’s tasted both success and disappointment. The important thing is that he can learn from both—and more important for us is that he can pass on his lessons.

  Martin Fowler

  April 2003

  Preface

  Leading software designers have recognized domain modeling and design as critical topics for at least 20 years, yet surprisingly little has been written about what needs to be done or how to do it. Although it has never been formulated clearly, a philosophy has emerged as an undercurrent in the object community, a philosophy I call domain-driven design.

  I have spent the past decade developing complex systems in several business and technical domains. In my work, I have tried best practices in design and development process as they have emerged from the leaders in object-oriented development. 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.