library / libdc52c2a720ec3213
Domain-Driven Design: Tackling Complexity in the Heart of Software
Eric Evans · 2003
In a sentence
Domain-Driven Design argues that the key to building complex, long-lived software is tightly coupling a rich, collaboratively developed domain model to every aspect of the implementation, from code to team communication.
Domain-Driven Design by Eric Evans is the definitive guide to tackling software complexity by placing the business domain at the center of development. Evans demonstrates, through extensive examples drawn from shipping systems, banking, PCB design, and loan syndication, that sustainable software emerges only when developers and domain experts collaborate to build a shared model expressed in a common language—one that pervades diagrams, conversations, and the code itself. The book provides a comprehensive vocabulary of patterns—Entities, Value Objects, Aggregates, Repositories, Factories, Services, Bounded Contexts, and more—that give teams precise tools for designing systems whose structure mirrors domain reality. It addresses not only fine-grained object design but also the strategic challenges of large systems: how to maintain model integrity across teams, how to distill a Core Domain from supporting concerns, and how to impose large-scale structure without stifling local design freedom. Whether a team is navigating a breakthrough insight, integrating legacy systems, or coordinating multiple bounded contexts, this book provides the conceptual framework and practical patterns to do so with clarity and discipline.
The four lenses
- Science
- Statistics
- Systems
- Strategy
Tags
The model
A causal model describing how design and team practices (domain collaboration, ubiquitous language, model-driven design, bounded contexts, distillation, supple design, large-scale structure) shape psychological and behavioral states (shared understanding, cognitive load, model integrity) and ultimately determine software outcomes (maintainability, evolvability, domain value, team effectiveness).
Knowledge Crunchingdesign lever
The iterative, collaborative process by which developers and domain experts together distill raw domain information—conversations, documents, existing systems—into a progressively refined and useful domain model through brainstorming, scenario walking, prototyping, and continuous experimentation.
Ubiquitous Languagedesign lever
A common, rigorously maintained language built from the domain model and used consistently by all team members—developers and domain experts alike—in speech, writing, diagrams, and code, so that every communication medium reinforces the same model concepts and terminology.
Model-Driven Designdesign lever
A design discipline in which software elements—classes, associations, modules—directly and literally correspond to elements of the domain model, so that the code is an expression of the model and changes to one necessitate changes to the other, eliminating the gap between analysis and implementation.
Layered Architecturedesign lever
An architectural pattern that isolates the domain layer from infrastructure, UI, and application concerns by organizing code into distinct layers (UI, Application, Domain, Infrastructure) with dependencies flowing only downward, ensuring domain logic is not contaminated by technical concerns.
Entity and Value Object Distinctiondesign lever
The deliberate design practice of classifying domain objects as Entities (defined by identity and continuity through a lifecycle) or Value Objects (defined solely by their attributes, immutable, and interchangeable), which guides decisions about identity management, sharing, copying, and lifecycle responsibility.
Aggregate Designdesign lever
The practice of clustering associated objects into Aggregates with a single root Entity, defining clear ownership and transactional consistency boundaries, and restricting external references to the root, so that invariants can be enforced and concurrent access managed without excessive locking.
Repository and Factory Pattern Usagedesign lever
The design practice of encapsulating object creation complexity in Factories and encapsulating persistence and retrieval in Repositories, so that the domain layer is freed from infrastructure concerns and client code interacts with domain objects through intention-revealing, model-focused interfaces.
Making Implicit Concepts Explicitdesign lever
The modeling practice of recognizing concepts that are implied in existing code or domain conversations—constraints, policies, processes, specifications—and representing them as first-class model elements (classes, interfaces, or explicit methods), making domain knowledge visible and manipulable in the design.
Supple Design Practicesdesign lever
A cluster of detailed design techniques—Intention-Revealing Interfaces, Side-Effect-Free Functions, Assertions, Conceptual Contours, Standalone Classes, and Closure of Operations—that together produce a design that is easy to understand, predict, and combine, enabling client developers to use and extend the model confidently.
Bounded Context Definitiondesign lever
The strategic practice of explicitly defining the boundaries within which a particular domain model applies—in terms of team organization, codebase, and database schema—and maintaining strict internal consistency within those bounds while acknowledging that different models apply elsewhere.
Continuous Integration Practicedesign lever
The team process of frequently merging all code and implementation artifacts, running automated tests to detect model fragmentation early, and continuously exercising the Ubiquitous Language to maintain a unified, internally consistent model within a Bounded Context.
Context Mapdesign lever
A strategic artifact that identifies all models in play on a project, defines their Bounded Contexts, and documents the relationships and translation mechanisms between them, giving the entire team a shared understanding of the overall model topology and integration points.
Core Domain Distillationdesign lever
The strategic practice of identifying the distinctive, highest-value subset of the domain model—the Core Domain—and separating it from Generic Subdomains and Cohesive Mechanisms, focusing the best design talent and deepest knowledge on the Core while treating supporting elements as lower-priority concerns.
Large-Scale Structuredesign lever
An overarching set of concepts, rules, or organizing principles—such as Responsibility Layers, System Metaphor, Knowledge Level, or Pluggable Component Framework—that spans the entire system or large portions of it, providing a shared vocabulary and design framework that allows team members to understand any part's role in the whole without mastering every detail.
Shared Domain Understandingpsychological state
The degree to which all team members—developers and domain experts alike—hold a common, accurate, and sufficiently deep understanding of the domain model, its concepts, relationships, and rules, enabling coordinated decision-making and reducing translation errors.
Model Integritypsychological state
The internal consistency of the domain model within its applicable context—specifically the absence of contradictory rules, ambiguous terms, or false cognates—such that every term has a single unambiguous meaning and all rules are mutually compatible, enabling reliable software behavior and clear communication.
Cognitive Load on Developerspsychological state
The mental burden placed on developers when working with the codebase and model—including the need to simultaneously track complex interdependencies, translate between multiple terminologies, and reverse-engineer implicit domain rules from procedural code—which constrains the complexity of software that can be reliably built and maintained.
Domain Knowledge Accumulation in Teambehavioral pattern
The degree to which the development team collectively builds up deep, accurate, and practically useful knowledge of the business domain over time—through continuous collaboration with domain experts, iterative modeling, and hands-on implementation—creating a stable core of expertise that improves modeling and design quality.
Refactoring Toward Deeper Insightbehavioral pattern
The ongoing behavioral practice of continuously improving the domain model and its implementation—not merely for code cleanliness but to better capture domain understanding—making implicit concepts explicit, seeking supple designs, and embracing breakthroughs when they arise rather than deferring or avoiding disruptive but necessary model changes.
Domain Complexitycontextual condition
A contextual condition reflecting the inherent complexity of the business domain being modeled—including the number of concepts, the intricacy of their interrelationships, the prevalence of exceptions and special cases, and the rate of change of business rules—which moderates the impact of DDD practices on outcomes.
Team Skill and Collaboration Qualitycontextual condition
A contextual condition capturing the technical design skill, domain knowledge, and quality of interpersonal collaboration among team members—including the degree of developer-domain-expert engagement, shared code ownership, and collective commitment to MODEL-DRIVEN DESIGN—which moderates the effectiveness of DDD practices.
Software Maintainabilityoutcome metric
The degree to which the software system can be understood, modified, extended, and debugged by developers over time without disproportionate effort—reflecting the clarity of the domain model in the code, the isolation of concerns, and the suppleness of the design.
Software Evolvabilityoutcome metric
The capacity of the software system to accommodate new requirements, deeper domain insights, and changing business conditions over extended periods without requiring prohibitive redesign—enabled by supple design, well-distilled models, and appropriate bounded context boundaries.
Domain Value Deliveryoutcome metric
The degree to which the software system delivers genuine business value by accurately capturing and enforcing the Core Domain's rules and concepts, enabling users to perform their work more effectively, and differentiating the application in ways that matter to the business.
Team Communication Effectivenessoutcome metric
The quality and efficiency of communication among team members and between developers and domain experts—characterized by shared terminology, reduced translation overhead, and the ability to discuss model changes and requirements without ambiguity or misunderstanding.
How they connect
- knowledge crunching → predicts shared domain understanding
- knowledge crunching → predicts domain knowledge accumulation
- ubiquitous language → predicts shared domain understanding
- ubiquitous language → predicts team communication effectiveness
- model driven design → predicts model integrity
- model driven design − predicts cognitive load on developers
- layered architecture → predicts model integrity
- entity value object distinction − predicts cognitive load on developers
- aggregate design → predicts model integrity
- repository factory pattern − predicts cognitive load on developers
- making implicit explicit → predicts shared domain understanding
- supple design practices − predicts cognitive load on developers
- supple design practices → predicts software evolvability
- bounded context definition → predicts model integrity
- continuous integration practice → predicts model integrity
- context map → predicts shared domain understanding
- core domain distillation → predicts domain value delivery
- large scale structure − predicts cognitive load on developers
- shared domain understanding → predicts software maintainability
- shared domain understanding → predicts domain value delivery
- model integrity → predicts software maintainability
- cognitive load on developers − predicts software evolvability
- domain knowledge accumulation → predicts shared domain understanding
- refactoring toward deeper insight → predicts model integrity
- refactoring toward deeper insight → predicts software evolvability
- domain complexity → moderates knowledge crunching
- team skill and collaboration → moderates model driven design
- software maintainability → predicts software evolvability
- software evolvability → predicts domain value delivery
- team communication effectiveness → predicts shared domain understanding
The process
This book presents a comprehensive playbook for Domain-Driven Design (DDD), a methodology for developing complex software projects where the primary focus is on the core business domain. The overall process begins with strategic design, where practitioners assess the project landscape, distill the essential 'core domain,' and partition the system into distinct 'bounded contexts' with clear relationships defined in a 'context map.' This strategic framework sets the stage for the core activity of DDD: an iterative cycle of model-driven design and refinement. Within this cycle, developers and domain experts collaborate closely to build a shared understanding and a 'ubiquitous language' that is reflected directly in the code. The playbook then details the tactical patterns used to build a rich, expressive domain model. This includes classifying model elements (entities, value objects, services), managing object lifecycles with aggregates, factories, and repositories, and implementing the model with 'supple design' patterns that make the code intention-revealing and robust. Architectural patterns, such as layered architecture, provide a large-scale structure to organize the code and isolate the domain logic. Finally, the playbook addresses the challenges of large, multi-team projects. It provides processes for managing interactions between bounded contexts, either collaboratively through customer-supplier relationships or defensively with an 'anticorruption layer.' Supporting practices like continuous integration ensure the model's integrity is maintained over time. The entire approach is governed by a set of principles for making strategic decisions, emphasizing that design is an ongoing, emergent process of discovery and refinement, not a one-time, top-down activity.
Governing Strategic Design
To establish a shared understanding of the project's strategic landscape and create a framework for making effective, collaborative design decisions across teams.
When to use: At the beginning of a project, when assessing an existing complex system, or whenever strategic alignment across teams is needed.
Step 1Assess the current state of the project by drawing a preliminary Context Map to visualize relationships and identify ambiguities.
Entry: The project has multiple interacting parts or teams.
Exit: A visual representation of the system's components and their relationships is created.
In: Existing project structure, Communication artifacts · Out: Initial CONTEXT MAP
ch18
Step 2Evaluate the language used in the project to determine if a Ubiquitous Language exists and is consistently applied within its context.
Entry: An initial assessment of the project structure is complete.
Exit: An understanding of the state of the project's shared language.
In: Team communication, Code and documentation · Out: Language assessment
ch18
Step 3Assess the team's skills, domain knowledge, and the suitability of the technology for a model-driven design approach.
Exit: A clear picture of the team's capabilities and technological constraints.
In: Team composition, Current technology stack · Out: Capability assessment
ch18
Step 4Foster an environment where strategic design can emerge organically from collaboration among developers.
Entry: A team of skilled communicators is in place.
Exit: Teams are actively collaborating on design decisions.
- Deciding to adopt, modify, or discard emerging design ideas.
In: A diverse team of developers, Effective communication channels · Out: Organically developed set of strategic principles
ch18
Step 5Establish a minimalist, evolving framework for making strategic design decisions.
Entry: A need for a coherent design strategy is identified.
Exit: A flexible and understood decision-making process is in place.
In: Feedback from development teams · Out: A coherent and flexible strategic design
ch18
Distilling the Core Domain
To identify, separate, and highlight the most critical and valuable part of the domain model, ensuring that development effort is focused on the primary business value.
When to use: During strategic design to focus the project, or when a large project is losing focus and becoming bogged down by complexity in generic subdomains.
Step 1Identify the Core Domain that represents the essential business functionalities and competitive advantage.
Entry: A general understanding of the business domain exists.
Exit: A consensus is reached on what constitutes the Core Domain.
- Deciding which functionalities are truly core versus which are generic or supporting.
In: Existing domain models, Knowledge from domain experts · Out: Identification of the Core Domain
ch16 · ch18
Step 2Create a concise Domain Vision Statement that articulates the value and purpose of the Core Domain.
Entry: The Core Domain has been identified.
Exit: A shared Domain Vision Statement is documented and understood by the team.
In: Understanding of the Core Domain · Out: DOMAIN VISION STATEMENT
ch16 · ch18
Step 3Visually highlight the Core Domain elements within the overall model.
Entry: The Core Domain is identified.
Exit: The Core Domain is clearly visible and distinguished in project artifacts.
In: Domain models, Diagramming tools · Out: Distillation document or highlighted models
ch16
Step 4Refactor the model to separate the Core Domain from generic subdomains.
Entry: The Core Domain has been identified.
Exit: The codebase is organized into modules that separate core and generic concerns.
In: Existing codebase · Out: Modularized code with a distinct Core Domain
ch16
Step 5Assign the most talented developers to work on the Core Domain.
Entry: The Core Domain is defined and separated.
Exit: Team assignments reflect the priority of the Core Domain.
ch16
Step 6Regularly review and iteratively refine the Core Domain definition.
Entry: An initial distillation is complete.
Exit: The Core Domain definition remains current with business priorities.
In: Team feedback, Evolving business insights · Out: Refined Core Domain definition
ch16
Defining Bounded Contexts
To establish clear boundaries within which a particular domain model is consistent and applies, preventing model corruption and ambiguity in large systems.
When to use: During the initial strategic design of a large system, or when an existing system suffers from model fragmentation and confusion.
Step 1Identify the different functionalities, subdomains, or separate responsibilities within the project.
Entry: An understanding of the project's overall scope exists.
Exit: Logical partitions of the system are identified.
In: Project scope, Team structures, System functionalities · Out: List of potential contexts
ch14
Step 2Define the context within which each model operates.
Entry: Potential contexts have been identified.
Exit: Each model is assigned to a specific context.
- Deciding where the boundary of one context ends and another begins.
In: Team organization charts, Code repository structure · Out: Defined bounded contexts
ch14
Step 3Explicitly set and document the boundaries of each context.
Entry: Contexts have been conceptually defined.
Exit: Context boundaries are physically manifested and documented.
Out: Documented context boundaries
ch14
Step 4Communicate the defined boundaries and the models within them to all team members.
Entry: Boundaries are documented.
Exit: All team members are aware of and understand the bounded contexts.
In: Documented context boundaries · Out: Shared team understanding of contexts
ch14 · ch15
Creating a Context Map
To visualize the boundaries of all bounded contexts and the relationships between them, providing a strategic overview of the entire system landscape.
When to use: During strategic design, after defining the initial bounded contexts, and as a communication tool throughout the project.
Step 1Identify each model in play and confirm its bounded context.
Entry: Bounded contexts have been initially defined.
Exit: A list of all models and their corresponding contexts is available.
In: Defined bounded contexts · Out: Inventory of models and contexts
ch15
Step 2Name each bounded context and integrate these names into the organization's ubiquitous language.
Entry: Contexts are identified.
Exit: All bounded contexts have official names.
Out: Named bounded contexts
ch15
Step 3Draw the boundaries of each context on a diagram.
Entry: Contexts are named.
Exit: A diagram showing the boundaries of all contexts is created.
In: Named bounded contexts · Out: Visual context map
ch15 · ch18
Step 4Describe the points of contact between the models, labeling the relationship between them.
Entry: Context boundaries are drawn.
Exit: All inter-context relationships are identified and labeled on the map.
- Deciding which relationship pattern best describes the interaction between two contexts.
In: Understanding of inter-system communication · Out: Context map with labeled relationships
ch15
Step 5Share the context map with all team members and ensure it is understood and maintained.
Entry: The context map is drafted.
Exit: The context map is a shared, living document used by all teams.
In: Drafted context map · Out: Shared and maintained context map
ch15
Iterative Model-Driven Design and Refinement
To develop a deep understanding of a complex domain and create a useful, supple software model through a continuous cycle of collaboration, modeling, implementation, and refinement.
When to use: Throughout the lifecycle of a software project that is applying Domain-Driven Design.
Step 1Engage domain experts in collaborative discussions to gather and crunch domain knowledge.
Entry: Access to domain experts is available.
Exit: Initial, informal models and a shared vocabulary begin to form.
- Determining which concepts are significant enough to be included in the model.
In: Access to domain experts, Initial knowledge of domain terminology · Out: Informal models (diagrams), Key terms and concepts
ch01 · ch09 · ch19
Step 2Develop a comprehensive domain model that captures the essential concepts and relationships.
Entry: Initial knowledge crunching has occurred.
Exit: A version of the domain model is documented and understood by the team.
In: Insights from knowledge crunching · Out: Domain model
ch03
Step 3Use the domain model to drive the software design and implementation.
Entry: A domain model exists.
Exit: Software implementation reflects the domain model.
In: Domain model · Out: Software design and code
ch03
Step 4Create simple prototypes or write code based on the model to get rapid feedback.
Entry: A version of the model is ready for implementation.
Exit: A working piece of software or prototype is available for feedback.
In: Domain model · Out: Software prototype, Implemented features
ch01 · ch03
Step 5Continuously refactor the model and code based on new insights.
Entry: Feedback from implementation or users is available.
Exit: The model and code are updated to reflect the latest understanding of the domain.
- Deciding whether a new insight requires a small refactoring or a major redesign.
In: Feedback from software testing, Insights on code efficiency, User feedback · Out: Refined domain model, Refactored code
ch03 · ch08 · ch13 · ch19
Step 6Repeat the cycle of collaboration, modeling, coding, and refinement.
ch01 · ch03 · ch19
Establishing a Ubiquitous Language
To create a shared, rigorous, and unambiguous language between developers and domain experts that is used in all project communications and is directly reflected in the software model and code.
When to use: Continuously throughout the project lifecycle within a bounded context.
Step 1Develop a clear domain model that encapsulates the key concepts of the project.
Entry: The team has started the knowledge crunching process.
Exit: An initial domain model exists.
In: Domain knowledge from stakeholders · Out: Initial domain model
ch02
Step 2Commit the entire team to using the language in all forms of communication.
Entry: An initial language based on the model is forming.
Exit: The team consistently uses the language in all communications.
In: Commitment from team members
ch02
Step 3Engage in continuous experimentation and refinement of the language.
Entry: The language is in use.
Exit: The language becomes more precise and expressive over time.
- Deciding when to update terminology based on new insights.
In: Feedback from domain experts and developers · Out: Refined Ubiquitous Language
ch02
Step 4Refactor the code to align with changes in the Ubiquitous Language.
Entry: A change in the language has been agreed upon.
Exit: The codebase reflects the updated language.
In: Changes to the Ubiquitous Language · Out: Refactored code
ch02 · ch10
Step 5Document changes to the language to ensure all team members remain aligned.
Entry: The language has been refined.
Exit: Changes are documented and accessible to the team.
Out: Updated documentation
ch02
Defining and Classifying Model Elements
To create a clear, robust, and well-organized domain model by categorizing objects based on their characteristics and responsibilities, simplifying their relationships, and grouping them into cohesive modules.
When to use: During the iterative modeling process, when designing the specific classes and objects that will make up the domain layer.
Step 1Distinguish between Entities, Value Objects, and Services within the model.
Entry: Objects and concepts have been identified from knowledge crunching.
Exit: Each conceptual object in the domain is classified.
- Choosing whether an object is an Entity, Value Object, or Service.
In: A collection of objects representing domain concepts · Out: Classified model elements
ch05
Step 2Define Entities as objects with a distinct identity that persists through time, even as their attributes change.
Exit: Entities are clearly identified in the model.
ch05
Step 3Define Value Objects as objects that represent descriptive aspects of the domain and are identified only by their attributes, not a unique ID.
Exit: Value Objects are clearly identified in the model.
ch05
Step 4Define Services for significant domain operations that do not naturally belong to an Entity or Value Object.
Entry: An operation has been identified that doesn't fit within an existing object.
Exit: The operation is encapsulated in a well-defined, stateless Service.
- Determining if an operation should be a Service or a method on an Entity.
In: Domain operations · Out: Defined domain services
ch05
Step 5Simplify and clarify associations between objects.
Entry: Relationships between objects have been identified.
Exit: Associations in the model are simple, explicit, and reflect domain constraints.
- Deciding which strategy to use for simplifying an association (direction, qualifier, or elimination).
In: A model that includes object associations · Out: A clearer implementation of object associations
ch05
Step 6Group related model components into cohesive Modules.
Entry: A number of model elements (classes, objects) exist.
Exit: The model is organized into a set of cohesive, loosely coupled modules.
- Choosing how to categorize objects into modules.
In: Various model elements · Out: A structured and coherent modular design
ch05
Designing with Aggregates, Factories, and Repositories
To manage the lifecycle of domain objects, ensuring their integrity by grouping them into consistent units (Aggregates), encapsulating their creation (Factories), and providing a clean interface for their retrieval and storage (Repositories).
When to use: During tactical design, after initial model elements like Entities and Value Objects have been identified.
Step 1Define Aggregate boundaries to group related objects that should be treated as a single unit.
Entry: A set of associated objects with invariants to protect has been identified.
Exit: The Aggregate boundary is clearly defined.
- Deciding what objects should be included in the aggregate.
In: A set of associated objects, Rules for invariants that must be maintained · Out: Defined aggregate
ch06
Step 2Identify one Entity within the Aggregate to be the Root.
Entry: The Aggregate boundary is defined.
Exit: A single root entity for the aggregate is identified.
- Determining which object will serve as the root entity.
Out: Identified aggregate root
ch06
Step 3Implement Factories to encapsulate the creation of complex objects and Aggregates.
Entry: The creation logic for an object or Aggregate is complex or involves enforcing invariants.
Exit: Object creation is handled by a Factory, simplifying client code.
- Choosing whether to use a factory method on the aggregate root or a standalone factory class.
In: Parameters required for object creation · Out: Newly created instances of objects or aggregates
ch06
Step 4Define and implement Repositories to manage access to Aggregate roots.
Entry: Aggregates need to be persisted and retrieved.
Exit: A repository interface is defined for accessing aggregate roots.
- Deciding on the query methods needed by clients.
- Choosing which aggregates require direct repository access.
In: Criteria for identifying objects · Out: Retrieved aggregate root objects
ch06 · ch07
Applying Supple Design Patterns
To create a flexible, expressive, and clear implementation of the domain model that is easy to understand, use, and refactor.
When to use: During the implementation phase of the model-driven design cycle, and during refactoring.
Step 1Design Intention-Revealing Interfaces.
Entry: A class or method is being designed.
Exit: The names of program elements clearly convey their intent.
- Choosing the most appropriate name to communicate functionality.
In: Knowledge of the domain language, Understanding of the method's functionality · Out: Clearly named classes and methods
ch10
Step 2Create Side-Effect-Free Functions.
Entry: An operation is being designed.
Exit: The operation is clearly either a command or a query, not both.
- Determining whether a function should alter state or simply retrieve information.
Out: Functions that do not have side effects
ch10
Step 3Use Assertions to make assumptions explicit.
Entry: The behavior of an operation needs to be guaranteed.
Exit: State expectations are clearly documented in code or tests.
In: Knowledge of the expected behavior of operations · Out: Code with explicit assertions or tests
ch10
Step 4Decompose the design into small, cohesive units.
Entry: A class or method has too many responsibilities.
Exit: Functionality is separated into cohesive, independent units.
- Choosing how fine-grained each component should be.
In: Analysis of existing design · Out: Modular components
ch10
Step 5Apply established design patterns like STRATEGY and COMPOSITE to clarify the model.
Entry: The model contains variable algorithms or hierarchical structures.
Exit: Complexity is managed by encapsulating it within a standard design pattern.
- Choosing the appropriate design pattern for the problem.
In: Understanding of design patterns · Out: A clearer and more flexible model
ch12
Establishing a Large-Scale Structure
To impose a coherent organizational framework on a complex software system, improving clarity, separating concerns, and guiding development.
When to use: When a system's complexity grows to the point where a lack of coherence hinders development, or during the initial design of a large system.
Step 1Assess the current state of the system and identify areas of complexity or tangled concerns.
Entry: The system has grown complex and difficult to understand.
Exit: Areas requiring better organization are identified.
In: Existing system architecture · Out: Analysis of system complexity
ch17
Step 2Brainstorm and choose an overarching structure that can impose order.
Entry: A need for structure has been identified.
Exit: A large-scale structure has been chosen.
- Choosing which structure to impose (e.g., layers vs. metaphors).
In: Knowledge of the problem domain, Team members' expertise · Out: Chosen architectural pattern
ch17
Step 3Define the conceptual layers or parts of the chosen structure and their responsibilities.
Entry: A structure has been chosen.
Exit: The roles and responsibilities of each part of the structure are defined.
Out: Definition of architectural layers/components
ch04 · ch17
Step 4Establish rules for interaction between the parts of the structure.
Entry: Layers/components are defined.
Exit: Interaction rules are established and understood.
Out: Architectural rules
ch04
Step 5Refactor the code to conform to the newly established structure.
Entry: The new structure and its rules are defined.
Exit: The codebase is organized according to the chosen large-scale structure.
In: Existing codebase · Out: Refactored code
ch04 · ch17
Step 6Integrate the language of the large-scale structure into the team’s ubiquitous language.
Entry: The structure is implemented.
Exit: The structure is part of the team's shared understanding and vocabulary.
ch17
Managing Context Interactions
To establish clear, explicit patterns for how different bounded contexts communicate and relate to each other, preserving the integrity of their respective models.
When to use: When a feature requires two or more bounded contexts to interact, or when integrating a new system with a legacy system.
Step 1Identify the relationship between the interacting teams/contexts (e.g., upstream/downstream).
Entry: An integration point between two contexts is needed.
Exit: The upstream/downstream relationship is identified.
In: Context Map · Out: Identified team relationship
ch15
Step 2Choose an appropriate relationship pattern based on the level of collaboration and influence.
Entry: The team relationship is understood.
Exit: A specific interaction pattern is chosen.
- Deciding between collaborative patterns (Customer/Supplier) and defensive patterns (Anticorruption Layer).
Out: Chosen interaction pattern
ch15
Step 3If a Customer/Supplier relationship is chosen, formalize the collaboration.
Entry: Customer/Supplier pattern is chosen.
Exit: A collaborative process for integration is established.
- Deciding which features to prioritize.
In: Feature requirements from downstream team · Out: Prioritized feature list, Jointly developed acceptance tests
ch15
Step 4If an Anticorruption Layer is chosen, design and implement it to isolate the internal model.
Entry: Anticorruption Layer pattern is chosen.
Exit: An effective anticorruption layer is implemented and tested.
- Deciding on the structure and functionality of the layer.
In: Specifications of the external system · Out: Anticorruption Layer
ch15
Practicing Continuous Integration
To maintain the integrity and consistency of the model within a bounded context by frequently merging and validating all code changes from the team.
When to use: Continuously throughout the development lifecycle.
Step 1Establish a systematic, automated process for merging, building, and testing code changes.
Entry: A team of developers is working in a shared codebase.
Exit: An automated build and test pipeline is in place.
In: Source code repository, Automated testing tools · Out: CI pipeline
ch14
Step 2Schedule regular integration of work from all developers in the bounded context.
Entry: The CI pipeline is in place.
Exit: Code is merged and integrated on a frequent, regular basis.
- Deciding on the frequency of integration.
In: Code changes from team members · Out: Integrated codebase
ch14
Step 3Implement a comprehensive suite of automated tests.
Entry: The CI pipeline is in place.
Exit: A robust suite of automated tests provides confidence in the integrated code.
Out: Automated test suite
ch14
Step 4Ensure the team consistently uses the Ubiquitous Language when discussing the model and code.
Exit: Team communication about the model is clear and consistent.
ch14
Deciding on a Major Redesign
To make a conscious, well-reasoned decision about whether to undertake a significant refactoring or redesign of the model based on a breakthrough insight.
When to use: When the team has a 'breakthrough' moment and realizes a new model would be substantially better, but the cost of change is high.
Step 1Acknowledge that a breakthrough insight has occurred that challenges the current model.
Entry: The team is engaged in continuous refinement and refactoring.
Exit: A potential new model or design has been conceptualized.
In: Team insights from refactoring · Out: Proposed new model design
ch08
Step 2Assess the time and effort required to implement the new model design.
Entry: A new model has been proposed.
Exit: An estimate of the redesign effort is available.
Out: Effort estimate
ch08
Step 3Evaluate the feasibility of solving existing problems with the current design.
Entry: The cost of the redesign is estimated.
Exit: A comparison of options (redesign vs. patch) is complete.
Out: Comparative analysis
ch08
Step 4Determine the impact on future development if the redesign is not executed.
Exit: The long-term consequences of not redesigning are understood.
Out: Long-term impact assessment
ch08
Step 5Gather team input and build consensus on the best path forward.
Entry: All assessments are complete.
Exit: The development team has a unified position.
In: Team insights · Out: Team consensus
ch08
Step 6Secure managerial approval to proceed with the redesign.
Entry: The team has reached consensus.
Exit: A strategic go/no-go decision is made.
- Weighing immediate project deadlines against long-term effectiveness.
In: Managerial support · Out: A strategic go-ahead to commence the redesign, A revised project timeline
ch08
The story
The reader Software developers and architects working on complex, business-critical systems who want to build software that genuinely reflects and serves its domain, remaining maintainable and valuable over time.
External problem
The codebase grows increasingly tangled, domain logic leaks into infrastructure, and each new feature becomes harder to add; the software stops serving the business well.
Internal problem
Developers feel overwhelmed, disconnected from the business they are supposed to serve, and vaguely aware that the design is not capturing what really matters—yet unsure how to fix it.
Philosophical problem
It is wrong for complex, mission-critical software to be a pile of ad-hoc mechanisms that no one fully understands; software should be a clear, living expression of domain knowledge.
The plan
- Build a shared Ubiquitous Language with domain experts and let it pervade all communication and the code.
- Establish a Model-Driven Design in which code directly expresses the domain model, binding implementation and model tightly together.
- Apply the building-block patterns—Entities, Value Objects, Services, Aggregates, Factories, Repositories—to give the domain layer clear, robust structure.
- Continuously refactor toward deeper insight, making implicit concepts explicit and seeking supple design through Intention-Revealing Interfaces, Side-Effect-Free Functions, and Assertions.
- Map the strategic landscape with Bounded Contexts and a Context Map, choosing appropriate integration patterns (Shared Kernel, Customer/Supplier, Anticorruption Layer, etc.).
- Distill the Core Domain, separating it from Generic Subdomains and Cohesive Mechanisms so that the best effort is invested where it matters most.
- Impose a fitting large-scale structure (Responsibility Layers, Knowledge Level, etc.) that evolves with the system and keeps the overall design comprehensible.
Success
- The codebase becomes a clear expression of domain knowledge that domain experts can recognize and validate.
- New features align naturally with the existing model rather than requiring workarounds.
- Developers accumulate deep domain knowledge that makes them more effective over time.
- The team communicates precisely and efficiently using a shared language that spans conversations, diagrams, and code.
- The software remains changeable and valuable years after initial delivery, as demonstrated by the Evant story.
- Breakthroughs to deeper models accelerate development rather than derailing it.
At stake
- The codebase becomes an unmaintainable legacy that only the original authors understand, if anyone.
- Business rules are scattered across UI, database scripts, and application code, making change expensive and risky.
- Domain experts and developers speak past each other, leading to software that technically works but misses the point.
- The team loses the ability to respond to changing business requirements without heroic effort.
- The most talented developers flee to infrastructure work, leaving the Core Domain to the least experienced people.
- The project is cancelled, replaced, or reduced to a feature-frozen legacy long before its potential value is realized.
Chapter by chapter
ch01Crunching Knowledge
This chapter illustrates the process of transforming fragmented knowledge into a coherent model through iterative collaboration, emphasizing the value of knowledge crunching in software development without prior domain familiarity.
- Collaboration between software developers and domain experts is essential for creating effective and meaningful software solutions.
- Effective modeling arises from a disciplined exploration of domain knowledge, capturing essential insights that superfluous details obscure.
- Iterative feedback is crucial; early prototypes play a key role in refining models and specifications through active engagement.
- A shared vocabulary enriches team discussions, enabling clearer communication and mutual understanding of complex concepts.
ch02Communication and the Use of Language
Effective software development hinges on the use of a UBIQUITOUS LANGUAGE that bridges the gap between domain experts and developers, ensuring clarity and shared understanding throughout the project.
ch03Binding Model and Implementation
This chapter critiques traditional separation between domain models and implementation, arguing for a unified approach where effective software design directly reflects a comprehensive domain model.
ch04Isolating the Domain
This chapter argues for the vital separation of the domain layer in software applications, emphasizing its role in allowing clean, coherent, and manageable designs free from the obfuscation of ancillary system components.
- The part of the software that specifically solves problems from the domain usually constitutes only a small portion of the entire software system, yet its importance is disproportionate to its size.
- Isolating the domain ensures that domain logic evolves clearly, without being muddled by interface or infrastructure concerns.
- Creating programs that can handle very complex tasks calls for separation of concerns, which allows focused concentration on different parts of both design and development.
- Successful applications utilize layered architectures which specialize roles from user interaction to infrastructure support, enhancing the maintainability of complex systems.
ch05A Model Expressed in Software
This chapter argues that successful software implementation requires a detailed understanding of model elements, particularly the distinctions between entities, value objects, and services, while maintaining a focus on practical design and domain-specific insights.
- Careful classification of model elements into entities, value objects, and services is fundamental for bridging the gap between design and implementation.
- Associations in a model can complicate implementations; simplifying these through clear directional constraints is essential.
- Entities must be defined by their continuity and identity, while value objects serve primarily as descriptors without identity.
- The thoughtful inclusion of services respects the operational boundaries of entities and value objects, enhancing model clarity.
ch06The Life Cycle of a Domain Object
This chapter explores the life cycle of domain objects, emphasizing the importance of maintaining integrity through various design patterns, particularly aggregates, factories, and repositories.
- Every domain object has a life cycle that demands rigorous management to ensure data integrity.
- Aggregates provide clear ownership and boundaries necessary for maintaining invariants within complex object relationships.
- Factories should encapsulate all aspects of object creation and reconstitution, safeguarding internal complexity from client exposure.
- Repositories simplify access to aggregates while abstracting the complexities of underlying storage technologies.
ch07Using the Language: An Extended Example
This chapter illustrates the application of a model-driven design language through a hypothetical project to develop software for a cargo shipping company, detailing how various patterns can be integrated and refined in practice.
- A robust class diagram provides the backbone for a coherent model, translating complex business requirements into manageable components.
- Utilizing a layered architecture helps to clarify roles within the system, promoting maintainability and scalability.
- The distinction between entities and value objects is crucial for understanding system behavior and managing state effectively.
- Iterative refinement is key: your model should evolve as new insights are gained during development cycles.
ch08Breakthrough
An unexpected breakthrough in software design emerges from continuous refactoring, leading to a profound yet challenging transformation in understanding and modeling complex systems.
- Breakthrough moments in software design often arise from a long process of incremental refactoring, rather than sudden leaps of insight.
- A deep model captures the realities of the business, leading to clearer functionality and enhanced stakeholder trust.
- The introduction of a robust UBIQUITOUS LANGUAGE enables better communication among technical and non-technical team members, urging collaboration.
- Embracing change—despite the fear of upheaval—can yield significant long-term benefits for project success.
ch09Making Implicit Concepts Explicit
The process of transforming implicit concepts within a software domain model into explicit representations enhances clarity, communication, and design, ultimately resulting in a more effective application framework.
- Recognizing and articulating implicit concepts significantly enhances the quality and clarity of a domain model.
- Engaging actively with the language of domain experts and listening for terms that elicit recognition can reveal important concepts not previously included in the design.
- Iterative learning through trial and error not only aids in refining understanding but leads to deeper insights into domain complexity and solution adequacy.
- Investigating awkwardness in designs can uncover underlying concepts that need to be represented explicitly for effective modeling.
ch10Supple Design
This chapter argues for a design approach in software development that not only facilitates ease of refactoring and maintenance but also empowers developers through well-structured, intention-revealing interfaces and immutable value objects.
- Software design must prioritize the needs of developers to facilitate effective changes and adaptations over time.
- Intention-revealing interfaces serve as a powerful means of enhancing communication among developers.
- The separation of commands and queries minimizes cognitive overload and enhances the reliability of the code.
- Side-effect-free functions, typically arising from value objects, promote clarity and ease of use in complex systems.
ch11Applying Analysis Patterns
This chapter explores how developers can leverage analysis patterns from Martin Fowler to improve domain-driven design, enhancing the clarity and efficiency of complex systems.
ch12Relating Design Patterns to the Model
The chapter distinguishes between design patterns and domain patterns, arguing that established design patterns can be repurposed for domain modeling to enhance understanding and clarity in complex systems.
- Design patterns serve a dual purpose: they address technical issues and can provide conceptual clarity in domain modeling.
- The STRATEGY pattern aids in managing complexity by decoupling variable processes from the core functionalities, enhancing both application flexibility and maintainability.
- The COMPOSITE pattern allows for better representation of hierarchical relationships in models, thereby reducing redundant logic and making code simpler for developers to navigate.
- A pattern's application is only justified when it meaningfully connects with the conceptual concerns of the domain, reinforcing not just usability but also semantic relevance.
ch13Refactoring Toward Deeper Insight
This chapter argues that effective refactoring requires not just technical changes to code but also a deeper understanding of the domain, captured through consistent communication with domain experts and a willingness to adapt existing models.
- Refactoring toward deeper insight begins with a focus on the domain, emphasizing the importance of a coherent and representative model.
- Continuous exploration and refinement of the model with input from domain experts is crucial for effective software design.
- Developers must be willing to initiate refactoring even amid tidy code if the model no longer serves its purpose or aligns with evolving requirements.
- Group brainstorming sessions can yield significant insights and lead to the development of more refined models, fostering collaboration between developers and domain experts.
ch14Maintaining Model Integrity
This chapter explores the challenges of model management in software development, emphasizing the importance of establishing clear boundaries and relationships among multiple models to ensure software reliability.
- Model integrity is critically dependent on clear communication and proactive management of model boundaries within software development teams.
- A "bounded context" serves as a crucial tool for defining and maintaining the integrity of a model, allowing teams to establish clarity in their operations.
- Continuous integration is vital for identifying and mitigating model splinters before they become significant problems.
- Regularly cultivating a "ubiquitous language" is essential for developers to maintain a shared understanding and avoid misinterpretations of model components.
ch15Maintaining Model Integrity
This chapter discusses the importance of maintaining the integrity of software design through effective management of bounded contexts and their interactions, emphasizing the need for clear definitions, context mapping, and established relationships among models.
- A well-defined context map is crucial for maintaining the integrity of software models amidst complex team interactions.
- Clear naming conventions within the ubiquitous language enhance communication and reduce ambiguity across teams.
- Regular integration testing at the boundaries of contexts can serve as an effective preventative measure against model integrity issues.
- Understanding the relationships between various bounded contexts provides clarity and lends insight into potential areas for beneficial collaboration.
ch16Distillation
This chapter explores the necessity and methodology of strategically distilling complex domain models to isolate the core domain, thereby enhancing clarity and value in system design.
- Distillation is essential for navigating complexity in large systems; focus on the CORE DOMAIN to optimize software design.
- A well-defined CORE DOMAIN enhances team communication and decision-making, ultimately driving project success.
- Investing top resources in the CORE DOMAIN mitigates risks associated with neglecting business-critical components.
- Regular refinements and discussions around the CORE DOMAIN keep teams aligned and engaged in meaningful ways.
ch17Large-Scale Structure
This chapter explores the necessity and intricacies of establishing a coherent large-scale structure in complex software systems to enhance clarity, organization, and productivity across multiple independent developers.
ch18Bringing the Strategy Together
This chapter examines how to unify various strategic design efforts within software projects, emphasizing the need for collaborative decision-making among development teams rather than relying solely on top-down architecture.
- Strategic design must derive from collaboration among all relevant stakeholders, not just from a centralized architecture team.
- A strong UBIQUITOUS LANGUAGE is critical to bridging the gap between developers and architects, enhancing understanding and effectiveness.
- The concept of an evolving order in strategic design allows for adaptation and responsiveness in the face of real-world challenges.
- Organizations should prioritize communication and feedback loops to ensure that architectural decisions are grounded in the practical experiences of development teams.
ch19Conclusion
The conclusion reflects on the journey of various software projects employing domain-driven design, highlighting their successes and failures, ultimately arguing the importance of sustained engagement with software models to foster evolution and value over time.
Questions this book answers
- How do you build software that faithfully reflects deep domain knowledge?
- How should a domain model relate to the implementation?
- How do you maintain a shared language and consistent model across a large team?
- How do you manage model integrity when multiple models must coexist?
- How do you identify and protect the Core Domain?
Related in the library
- A Philosophy of Software Design (2nd Edition)shared: Systems
- Accelerate The Science of DevOpsshared: Systems
- Analytics Engineering with SQL and dbt Building Meaningful Data Models at Scaleshared: Systems
- Architecture Patterns with Pythonshared: Systems
- Artificial Intelligence - A Very Short Introductionshared: Systems
- Big Data_ A Very Short Introduction (Very Short Introductions)shared: Systems
Tools these methods power