Domain-Driven Design: Tacking Complexity In the Heart of Software / Edition 1

Hardcover (Print)
Used and New from Other Sellers
Used and New from Other Sellers
from $40.00
Usually ships in 1-2 business days
(Save 46%)
Other sellers (Hardcover)
  • All (15) from $40.00   
  • New (7) from $46.12   
  • Used (8) from $40.00   

Overview

“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.

“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

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

Kent Beck

“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®

The software development community widely acknowledges that domain modeling is central to software design. Through domain models, software developers are able to express rich functionality and translate it into a software implementation that truly serves the needs of its users. But despite its obvious importance, there are few practical resources that explain how to incorporate effective domain modeling into the software development process.

Domain-Driven Design fills that need. This is not a book about specific technologies. It offers readers a systematic approach to domain-driven design, presenting an extensive set of design best practices, experience-based techniques, and fundamental principles that facilitate the development of software projects facing complex domains. Intertwining design and development practice, this book incorporates numerous examples based on actual projects to illustrate the application of domain-driven design to real-world software development.

Readers learn how to use a domain model to make a complex development effort more focused and dynamic. A core of best practices and standard patterns provides a common language for the development team. A shift in emphasis—refactoring not just the code but the model underlying the code—in combination with the frequent iterations of Agile development leads to deeper insight into domains and enhanced communication between domain expert and programmer. Domain-Driven Design then builds on this foundation, and addresses modeling and design for complex systems and larger organizations.Specific topics covered include:

  • Getting all team members to speak the same language
  • Connecting model and implementation more deeply
  • Sharpening key distinctions in a model
  • Managing the lifecycle of a domain object
  • Writing domain code that is safe to combine in elaborate ways
  • Making complex code obvious and predictable
  • Formulating a domain vision statement
  • Distilling the core of a complex domain
  • Digging out implicit concepts needed in the model
  • Applying analysis patterns
  • Relating design patterns to the model
  • Maintaining model integrity in a large system
  • Dealing with coexisting models on the same project
  • Organizing systems with large-scale structures
  • Recognizing and responding to modeling breakthroughs

With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.

Read More Show Less

Product Details

  • ISBN-13: 9780321125217
  • Publisher: Addison-Wesley
  • Publication date: 8/22/2003
  • Edition description: New Edition
  • Edition number: 1
  • Pages: 528
  • Sales rank: 345,264
  • Product dimensions: 7.10 (w) x 9.30 (h) x 1.30 (d)

Meet the Author

Eric Evans is the founder of Domain Language, a consulting group dedicated to helping companies build evolving software deeply connected to their businesses. Since the 1980s, Eric has worked as a designer and programmer on large object-oriented systems in several complex business and technical domains. He has also trained and coached development teams in Extreme Programming.

Read More Show Less

Read an Excerpt

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 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.
  3. 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 concrete, I will use XP throughout the book as the basis for discussion of the interaction of design and process. The principles illustrated are easily adapted to other Agile Processes.

In recent years there has been a rebellion against elaborate development methodologies that burden projects with useless, static documents and obsessive upfront planning and design. Instead, the Agile Processes, such as XP, emphasize the ability to cope with change and uncertainty.

XP recognizes the importance of design decisions, but strongly resists upfront design. Instead, it puts an admirable effort into increasing communication, and increasing the project's ability to change course rapidly. With that ability to react, developers can use the "simplest thing that could work" at any stage of a project and then continuously refactor, making many small design improvements, ultimately arriving at a design that fits the customer's true needs.

This has been a much-needed antidote to some of the excesses of design enthusiasts. Projects have bogged down in cumbersome documents that provided little value. They have suffered "analysis paralysis", so afraid of an imperfect design that they made no progress at all. Something had to change.

Unfortunately, some of these new process ideas can be easily misinterpreted. Each person has a different definition of "simplest". Continuous refactoring without design principles to guide these small redesigns developers can produce a code base hard to understand or change - the opposite of agility. And, while fear of unanticipated requirements often leads to over-engineering, the attempt to avoid over-engineering can develop into another fear: The fear of any deep design thinking at all.

In fact, XP works best for developers with a sharp design sense. The XP process assumes that you can improve a design by refactoring, and that you will do this often and rapidly. But design choices make refactoring itself easier or harder. The XP process attempts to increase team communication. But model and design choices clarify or confuse communication. What is needed is an approach to domain modeling and design that pulls its weight.

This book intertwines design and development practice and illustrates how domain-driven design and agile development reinforce each other. A sophisticated approach to domain modeling within the context of an agile development process will accelerate development. The interrelationship of process with domain development makes this approach more practical than any treatment of "pure" design in a vacuum.

The Structure of This Book

The book is divided into four major sections:

Part I: Putting the Domain Model to Work presents the basic goals of domain-driven development that motivate the practices in later sections. Since there are so many approaches to software development, Part I defines terms, and gives an overview of the implications of placing the domain model in the role of driving communication and design.

Part II: The Building Blocks of Model-driven Design condenses a core of best practices in object-oriented domain modeling into a set of basic building blocks. The focus of this section is on bridging the gap between models and practical, running software. Sharing these standard patterns brings order to the design and makes it easy for team members to understand each other's work. Using standard patterns also establishes a common language, which all team members can use to discuss model and design decisions.

But the main point of this section is on the kind of decisions that keep the model and implementation aligned with each other, reinforcing each other's effectiveness. This alignment requires attention to the detail of individual elements. Careful crafting at this small scale gives developers a steady platform to apply the modeling approaches of Parts III and IV.

Part III: Refactoring Toward Deeper Insight goes beyond the building blocks to the challenge of assembling them into practical models that provide the payoff. Rather than jumping directly into esoteric design principles, this section emphasizes the discovery process. Valuable models do not emerge immediately. They require a deep understanding of the domain. That understanding comes from diving in, implementing an initial design based on a probably naive model, and then transforming it again and again. Each time the team gains insight, the model is transformed to reveal that richer knowledge, and the code is refactored to reflect the deeper model and make it's potential available to the application. Then, once in a while, this onion pealing leads to an opportunity to break through to a much deeper model, attended by a rush of profound design changes.

Exploration is inherently open-ended, but it does not have to be random. Part III delves into modeling principles that can guide choices along the way, and techniques that help direct the search.

Part IV: Strategic Design deals with situations that arise in complex systems, larger organizations, interactions with external systems and legacy systems. This section explores a triad of principles that apply to the system as a whole: Bounded Context, Distillation, and Large-Scale Structure. Strategic design decisions are made by teams, or even between teams. Strategic design enables the goals of Part I to be realized on a larger scale, for a big system or in an application that fits in an enterprise-wide network.

Throughout the book, discussions are illustrated with realistic examples, drawn from actual projects, rather than oversimplified "toy" problems.

Much of the book is written as a set of "patterns." The reader should be able to fully understand the material without concern about this device, but those who are interested in the style and format of the patterns can read Appendix A.

Who This Book Is Written For

This book is primarily written for developers of object-oriented software. Most members of a software project team can benefit from some parts of it. It will make most sense to people who are on a project, trying to do some of these things as they go through, or who have deep experience already to relate it to.Some knowledge of object-oriented modeling is necessary to benefit from this book. The examples include UML diagrams and Java code, so the ability to read those languages at a basic level is important, but it is unnecessary to have mastered the details of either UML or Java. Knowledge of Extreme Programming will add perspective to the discussions of development process, but the discussion should be understandable without background knowledge.

For an intermediate software developer, a reader who already knows something of object-oriented design and may have read one or two software design books, this book will fill in gaps and provide perspective on how object modeling fits into real life on a software project. It will help an intermediate developer make the jump to applying sophisticated modeling and design skills to practical problems.An advanced or expert software developer should be interested in the comprehensive framework for dealing with the domain. The systematic approach to design will help them in leading teams down this path. The coherent terminology will help them communicate with peers.

Readers of various backgrounds may wish to take different paths through the book, shifting emphasis to different points. I recommend all readers to start with the introduction to Part I, and Chapter 1. This book is a narrative, and can be read beginning to end, or from the beginning of any chapter. A skimmer who already has some grasp of a topic should be able to pick up the main points by reading headings and bolded text. A very advanced reader may want to skim Parts I and II, and will probably be most interested in Parts III and IV.

In addition to this core readership, the book will be of interest to analysts and to relatively technical project managers. Analysts can draw on the connection between model and design to make more effective contributions in the context of an "Agile" project. Analysts may also use some of the principles of strategic design to better focus and organize their work.

Project managers should be interested in the emphasis on making a team more effective and more focused on designing software meaningful to business experts and users. And, since, strategic design decisions are interrelated with team organization and work styles, these design decisions necessarily involve the leadership of the project, and have a major impact on the project's trajectory.

While an individual developer who understands domain-driven design will gain valuable design techniques and perspective, the biggest gains come when a team joins to apply a domain-driven design approach and move the domain model to the center of discourse of the project. The team members will share a language that enriches their communication and keeps it connected to the software. They will produce an implementation in step with the model, giving leverage to application development. They will share a map of how design work of different teams relates, and will systematically focus attention on the most features most distinctive and valuable to the organization.

A domain-driven design is a difficult technical challenge that can pay off big, opening opportunities just at the stage when most software projects begin to ossify into legacy.

Eric Evans, San Francisco, California, March 2003
http://domainlanguage.com

0321125215P04092003

Read More Show Less

Table of Contents

Foreword.

Preface.

Acknowledgments.

I. PUTTING THE DOMAIN MODEL TO WORK.

1. Crunching Knowledge.

Ingredients of Effective Modeling.

Knowledge Crunching.

Continuous Learning.

Knowledge-Rich Design.

Deep Models.

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.

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.

II. THE BUILDING BLOCKS OF A MODEL-DRIVEN DESIGN.

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.

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.

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.

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.

III. REFACTORING TOWARD DEEPER INSIGHT.

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.

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.

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.

11. Applying Analysis Patterns.

12. Relating Design Patterns to the Model.

STRATEGY (A.K.A. POLICY).

COMPOSITE.

Why Not FLYWEIGHT?

13. Refactoring Toward Deeper Insight.

Initiation.

Exploration Teams.

Prior Art.

A Design for Developers.

Timing.

Crisis as Opportunity.

IV. STRATEGIC DESIGN.

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.

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.

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.

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. 0321125215T08272003

Read More Show Less

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 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.
  3. 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 concrete, I will use XP throughout the book as the basis for discussion of the interaction of design and process. The principles illustrated are easily adapted to other Agile Processes.

In recent years there has been a rebellion against elaborate development methodologies that burden projects with useless, static documents and obsessive upfront planning and design. Instead, the Agile Processes, such as XP, emphasize the ability to cope with change and uncertainty.

XP recognizes the importance of design decisions, but strongly resists upfront design. Instead, it puts an admirable effort into increasing communication, and increasing the project's ability to change course rapidly. With that ability to react, developers can use the "simplest thing that could work" at any stage of a project and then continuously refactor, making many small design improvements, ultimately arriving at a design that fits the customer's true needs.

This has been a much-needed antidote to some of the excesses of design enthusiasts. Projects have bogged down in cumbersome documents that provided little value. They have suffered "analysis paralysis", so afraid of an imperfect design that they made no progress at all. Something had to change.

Unfortunately, some of these new process ideas can be easily misinterpreted. Each person has a different definition of "simplest". Continuous refactoring without design principles to guide these small redesigns developers can produce a code base hard to understand or change - the opposite of agility. And, while fear of unanticipated requirements often leads to over-engineering, the attempt to avoid over-engineering can develop into another fear: The fear of any deep design thinking at all.

In fact, XP works best for developers with a sharp design sense. The XP process assumes that you can improve a design by refactoring, and that you will do this often and rapidly. But design choices make refactoring itself easier or harder. The XP process attempts to increase team communication. But model and design choices clarify or confuse communication. What is needed is an approach to domain modeling and design that pulls its weight.

This book intertwines design and development practice and illustrates how domain-driven design and agile development reinforce each other. A sophisticated approach to domain modeling within the context of an agile development process will accelerate development. The interrelationship of process with domain development makes this approach more practical than any treatment of "pure" design in a vacuum.

The Structure of This Book

The book is divided into four major sections:

Part I: Putting the Domain Model to Work presents the basic goals of domain-driven development that motivate the practices in later sections. Since there are so many approaches to software development, Part I defines terms, and gives an overview of the implications of placing the domain model in the role of driving communication and design.

Part II: The Building Blocks of Model-driven Design condenses a core of best practices in object-oriented domain modeling into a set of basic building blocks. The focus of this section is on bridging the gap between models and practical, running software. Sharing these standard patterns brings order to the design and makes it easy for team members to understand each other's work. Using standard patterns also establishes a common language, which all team members can use to discuss model and design decisions.

But the main point of this section is on the kind of decisions that keep the model and implementation aligned with each other, reinforcing each other's effectiveness. This alignment requires attention to the detail of individual elements. Careful crafting at this small scale gives developers a steady platform to apply the modeling approaches of Parts III and IV.

Part III: Refactoring Toward Deeper Insight goes beyond the building blocks to the challenge of assembling them into practical models that provide the payoff. Rather than jumping directly into esoteric design principles, this section emphasizes the discovery process. Valuable models do not emerge immediately. They require a deep understanding of the domain. That understanding comes from diving in, implementing an initial design based on a probably naive model, and then transforming it again and again. Each time the team gains insight, the model is transformed to reveal that richer knowledge, and the code is refactored to reflect the deeper model and make it's potential available to the application. Then, once in a while, this onion pealing leads to an opportunity to break through to a much deeper model, attended by a rush of profound design changes.

Exploration is inherently open-ended, but it does not have to be random. Part III delves into modeling principles that can guide choices along the way, and techniques that help direct the search.

Part IV: Strategic Design deals with situations that arise in complex systems, larger organizations, interactions with external systems and legacy systems. This section explores a triad of principles that apply to the system as a whole: Bounded Context, Distillation, and Large-Scale Structure. Strategic design decisions are made by teams, or even between teams. Strategic design enables the goals of Part I to be realized on a larger scale, for a big system or in an application that fits in an enterprise-wide network.

Throughout the book, discussions are illustrated with realistic examples, drawn from actual projects, rather than oversimplified "toy" problems.

Much of the book is written as a set of "patterns." The reader should be able to fully understand the material without concern about this device, but those who are interested in the style and format of the patterns can read Appendix A.

Who This Book Is Written For

This book is primarily written for developers of object-oriented software. Most members of a software project team can benefit from some parts of it. It will make most sense to people who are on a project, trying to do some of these things as they go through, or who have deep experience already to relate it to.Some knowledge of object-oriented modeling is necessary to benefit from this book. The examples include UML diagrams and Java code, so the ability to read those languages at a basic level is important, but it is unnecessary to have mastered the details of either UML or Java. Knowledge of Extreme Programming will add perspective to the discussions of development process, but the discussion should be understandable without background knowledge.

For an intermediate software developer, a reader who already knows something of object-oriented design and may have read one or two software design books, this book will fill in gaps and provide perspective on how object modeling fits into real life on a software project. It will help an intermediate developer make the jump to applying sophisticated modeling and design skills to practical problems.An advanced or expert software developer should be interested in the comprehensive framework for dealing with the domain. The systematic approach to design will help them in leading teams down this path. The coherent terminology will help them communicate with peers.

Readers of various backgrounds may wish to take different paths through the book, shifting emphasis to different points. I recommend all readers to start with the introduction to Part I, and Chapter 1. This book is a narrative, and can be read beginning to end, or from the beginning of any chapter. A skimmer who already has some grasp of a topic should be able to pick up the main points by reading headings and bolded text. A very advanced reader may want to skim Parts I and II, and will probably be most interested in Parts III and IV.

In addition to this core readership, the book will be of interest to analysts and to relatively technical project managers. Analysts can draw on the connection between model and design to make more effective contributions in the context of an "Agile" project. Analysts may also use some of the principles of strategic design to better focus and organize their work.

Project managers should be interested in the emphasis on making a team more effective and more focused on designing software meaningful to business experts and users. And, since, strategic design decisions are interrelated with team organization and work styles, these design decisions necessarily involve the leadership of the project, and have a major impact on the project's trajectory.

While an individual developer who understands domain-driven design will gain valuable design techniques and perspective, the biggest gains come when a team joins to apply a domain-driven design approach and move the domain model to the center of discourse of the project. The team members will share a language that enriches their communication and keeps it connected to the software. They will produce an implementation in step with the model, giving leverage to application development. They will share a map of how design work of different teams relates, and will systematically focus attention on the most features most distinctive and valuable to the organization.

A domain-driven design is a difficult technical challenge that can pay off big, opening opportunities just at the stage when most software projects begin to ossify into legacy.

Eric Evans, San Francisco, California, March 2003
http://domainlanguage.com

0321125215P04092003

Read More Show Less

Customer Reviews

Be the first to write a review
( 0 )
Rating Distribution

5 Star

(0)

4 Star

(0)

3 Star

(0)

2 Star

(0)

1 Star

(0)

Your Rating:

Your Name: Create a Pen Name or

Barnes & Noble.com Review Rules

Our reader reviews allow you to share your comments on titles you liked, or didn't, with others. By submitting an online review, you are representing to Barnes & Noble.com that all information contained in your review is original and accurate in all respects, and that the submission of such content by you and the posting of such content by Barnes & Noble.com does not and will not violate the rights of any third party. Please follow the rules below to help ensure that your review can be posted.

Reviews by Our Customers Under the Age of 13

We highly value and respect everyone's opinion concerning the titles we offer. However, we cannot allow persons under the age of 13 to have accounts at BN.com or to post customer reviews. Please see our Terms of Use for more details.

What to exclude from your review:

Please do not write about reviews, commentary, or information posted on the product page. If you see any errors in the information on the product page, please send us an email.

Reviews should not contain any of the following:

  • - HTML tags, profanity, obscenities, vulgarities, or comments that defame anyone
  • - Time-sensitive information such as tour dates, signings, lectures, etc.
  • - Single-word reviews. Other people will read your review to discover why you liked or didn't like the title. Be descriptive.
  • - Comments focusing on the author or that may ruin the ending for others
  • - Phone numbers, addresses, URLs
  • - Pricing and availability information or alternative ordering information
  • - Advertisements or commercial solicitation

Reminder:

  • - By submitting a review, you grant to Barnes & Noble.com and its sublicensees the royalty-free, perpetual, irrevocable right and license to use the review in accordance with the Barnes & Noble.com Terms of Use.
  • - Barnes & Noble.com reserves the right not to post any review -- particularly those that do not follow the terms and conditions of these Rules. Barnes & Noble.com also reserves the right to remove any review at any time without notice.
  • - See Terms of Use for other conditions and disclaimers.
Search for Products You'd Like to Recommend

Recommend other products that relate to your review. Just search for them below and share!

Create a Pen Name

Your Pen Name is your unique identity on BN.com. It will appear on the reviews you write and other website activities. Your Pen Name cannot be edited, changed or deleted once submitted.

 
Your Pen Name can be any combination of alphanumeric characters (plus - and _), and must be at least two characters long.

Continue Anonymously
Sort by: Showing all of 2 Customer Reviews
  • Anonymous

    Posted December 28, 2003

    Re-introduces a new way to think about software design

    If you have even been involved in a software project (a) as a developer and did not know what the end product is going to be used for or how it will be used or (b) as an architect who spent countless hours with your stakeholders and domain experts trying to figure out how to go about architecting your application, then you should read this book. Read it again after you have read it for the first time. This book is packed with pointers, information, tips, how-tos, ¿down to earth¿ practical samples, and even conversational examples that one could have while gathering requirements. Evans in his book fills a wide gap that we all tend to come across while designing software applications. There are many software engineering processes out there, and each one tries to tackle the complexities of designing software applications for a given domain in its own way. Evans recognizes the tools and the processes that are popular in the industry, UML, Agile, and focuses on some aspects of the software engineering process that we tend to miss. He starts the book by talking about the importance of creating and having a Ubiquitous Language. There is a similar concept in the RUP, but not emphasizes as much ¿ or at all. Evans goes into a great detail on why, from the inception of a project, it is important to have a common language and gives many pointers on what makes up the Ubiquitous Language for each project: ¿Use the model as the backbone of a language. Commit the team to exercising that language relentlessly within the team and the in the code. Use the same language in diagrams, writing, and especially speech.¿ Parts II-IV of the book put domain-driven design in perspective, and show the reader thru examples and patterns, architectural patterns, design patterns and process patterns, the importance of having a consistent model that maps to the domain and how to go about achieving such model. In an essence, ¿Model-Driven Design discards the dichotomy of analysis model and design to search out a single model that serves both purposes¿. In summary, Evans did a great job in writing this book, and filling it with useful ways of designing and architecting software applications that target a domain, which in most cases we do not know much about.

    1 out of 1 people found this review helpful.

    Was this review helpful? Yes  No   Report this review
  • Anonymous

    Posted October 2, 2009

    No text was provided for this review.

Sort by: Showing all of 2 Customer Reviews

If you find inappropriate content, please report it to Barnes & Noble
Why is this product inappropriate?
Comments (optional)