Domain-Driven Design Quickly

1. Software is Deeply Rooted in its Domain

A useful package of software cannot be decoupled from that sphere of reality, the domain it is supposed to help us manage.

Understand the domain. Software exists to solve real-world problems or automate business processes. It is fundamentally connected to the specific area of reality it serves, known as the domain. Without a deep understanding of this domain, software cannot effectively enhance it and risks causing malfunction or chaos.

Domain experts are key. The people who truly understand the domain are the specialists working within it, not necessarily the software developers or analysts. Collaborating closely with domain experts is essential to extract the necessary knowledge. This raw knowledge must then be abstracted and organized into a model.

Software reflects the domain. Good software should incorporate the core concepts, elements, and relationships of its domain. The code itself should reflect this understanding, allowing someone knowledgeable in the domain to gain insight by reading the code. Software that isn't deeply rooted in its domain will struggle to adapt to change over time.

2. Forge a Ubiquitous Language with Domain Experts

Use the model as the backbone of a language.

Bridge the communication gap. Developers and domain experts often speak different languages, leading to misunderstandings and project failure. Developers think in terms of code artifacts, while experts use their domain-specific jargon. A common language is crucial for effective collaboration.

Model-based language. The solution is to create a shared language based directly on the domain model being developed. This "Ubiquitous Language" must be used consistently by everyone on the team in all forms of communication, including speech, writing, and diagrams. It ensures clarity and precision.

Language shapes the model. The process of creating and refining the Ubiquitous Language is iterative. As the team discusses and clarifies terms, the model itself evolves. Domain experts challenge awkward terms, while developers identify ambiguity, leading to a stronger, more accurate model that everyone understands.

3. Design Software Directly from the Domain Model

If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect.

Avoid analysis-design disconnect. Traditionally, analysis models are created separately from code design, often by different people. This leads to models that are analytically correct but impractical to implement, causing developers to deviate and the model to become irrelevant. Insight gained in one phase doesn't feed the other.

Model-driven implementation. The model should be constructed with software implementation in mind, involving developers from the start. The code design should literally reflect the domain model, making the mapping obvious. This tight coupling ensures the model remains relevant and the code accurately expresses domain concepts.

Code is model expression. Changes in the code should be seen as changes to the model, requiring careful consideration. Object-oriented programming languages are well-suited for this approach as they provide constructs like classes and associations that map directly to model elements. This makes the code more readable and maintainable.

4. Structure Applications with Clear Layers

Concentrate all the code related to the domain model in one layer and isolate it from the user interface, application, and infrastructure code.

Separate concerns. In complex applications, domain logic often gets mixed with UI, database, and other technical code. This entanglement makes the domain logic hard to understand, change, and test. Superficial technical changes can inadvertently break business rules.

Partition into layers. A standard architectural pattern is to divide the application into distinct layers, each depending only on the layers below it. This provides loose coupling and isolates concerns. A common structure includes:

• User Interface (Presentation): Handles user interaction.
• Application Layer: Coordinates tasks, holds task state (no business logic).
• Domain Layer: Contains the core business logic and object state.
• Infrastructure Layer: Provides technical support (persistence, messaging, etc.).

Focus the domain layer. By isolating the domain layer, its objects can focus solely on expressing the domain model and its behavior. They are free from responsibilities like displaying themselves or managing database access. This allows the domain model to become rich and clear, capturing essential business knowledge effectively.

5. Distinguish Core Domain Objects: Entities and Value Objects

When an object is distinguished by its identity, rather than its attributes, make this primary to its definition in the model.

Identity matters for Entities. Some domain objects have a continuous identity that persists throughout their lifecycle, regardless of their attributes. These are called Entities. Examples include a Customer (identified by customer ID) or a Bank Account (identified by account number). Their uniqueness is paramount.

Attributes matter for Value Objects. Other domain objects are defined solely by their attributes. They have no conceptual identity and are interchangeable if their attributes are the same. These are Value Objects. Examples include a Point (defined by coordinates) or an Address (defined by street, city, state).

Simplify design with Value Objects. Not every object needs an identity. Making objects Value Objects simplifies design by avoiding the complexity of tracking identity. Value Objects should ideally be immutable; once created, their attributes don't change. This allows them to be freely shared or copied without risking data integrity issues.

6. Define Domain Behavior with Services and Modules

When such a behavior is recognized in the domain, the best practice is to declare it as a Service.

Behavior that doesn't fit objects. Not all domain logic naturally belongs to an Entity or Value Object. Some operations represent significant processes or transformations that span multiple objects. Placing such behavior within a single object would violate its core responsibility and create undesirable coupling.

Introduce Services. For behavior that doesn't fit neatly into an object's state or identity, define it as a Service. Services are stateless operations that perform actions on or coordinate other domain objects. They encapsulate important domain concepts that are verbs rather than nouns in the Ubiquitous Language.

Organize with Modules. As the domain model grows, it becomes complex to manage. Modules are used to organize related concepts and tasks, reducing complexity. They group cohesive sets of classes and relationships, improving readability and maintainability by reducing coupling between different parts of the model.

7. Manage Object Lifecycle with Aggregates, Factories, and Repositories

It is difficult to guarantee the consistency of changes to objects in a model with complex associations.

Maintain data integrity. Domain models often involve complex networks of associated objects. Ensuring data consistency and enforcing invariants (rules that must always be true) across these relationships is challenging, especially with concurrent access or persistence. Uncontrolled access to interconnected objects can lead to corruption.

Group objects into Aggregates. An Aggregate is a cluster of associated objects treated as a single unit for data changes. It has a root Entity, which is the only object accessible from outside the boundary. All access and modifications to internal objects must go through the root, allowing the root to enforce invariants for the entire group.

Use Factories and Repositories. Creating complex objects or entire Aggregates can be complicated; Factories encapsulate this creation logic, hiding internal structure from clients. Repositories provide a means to retrieve existing Aggregate roots, abstracting away the details of persistence (like database queries) and providing the illusion of an in-memory collection.

8. Continuously Refine the Model for Deeper Insight

Sophisticated domain models are seldom developed except through an iterative process of refactoring, including close involvement of the domain experts with developers interested in learning about the domain.

Beyond technical refactoring. Refactoring isn't just about cleaning up code structure; it's also driven by new insights into the domain. As understanding deepens through collaboration with experts and feedback from implementation, the model needs to be refined. This iterative process is crucial for developing a truly incisive model.

Make implicit concepts explicit. Often, key domain concepts are initially hidden or implicit in discussions or awkward design sections. Listening to the Ubiquitous Language, identifying design awkwardness, reconciling contradictions, and consulting domain literature can reveal these concepts. Making them explicit in the model and code clarifies the design.

Refactor for clarity. Explicitly representing concepts like Constraints (invariants), Processes (complex operations often implemented as Services), and Specifications (rules for testing objects) improves model clarity. Encapsulating these concepts in dedicated objects simplifies the design and makes the business rules more visible and maintainable.

9. Preserve Model Integrity by Defining Bounded Contexts

Preserving the model integrity by striving to maintain one large unified model for the entire enterprise project is not going to work.

Avoid monolithic models. For large enterprise projects involving multiple teams, attempting to maintain a single, unified model across the entire system is impractical and leads to inconsistency. Code based on distinct, unintegrated models becomes buggy and confusing.

Define Bounded Contexts. The solution is to consciously divide the system into multiple models, each with a clearly defined boundary or "Bounded Context." Within its context, a model is kept strictly consistent and unified. Issues outside the boundary are not allowed to contaminate the model within.

Contexts guide organization. Bounded Contexts provide a logical framework for model evolution and team organization. Teams can work independently within their context, refining their model and implementation without constantly needing to synchronize with others, as long as the relationships between contexts are clearly defined.

10. Map and Strategize Relationships Between Contexts

Uncoordinated teams working on closely related applications can go racing forward for a while, but what they produce may not fit together.

Integrate distinct contexts. While Bounded Contexts allow independent development, the different parts of the system must ultimately work together. Defining the relationships between contexts is crucial. A Context Map is a document or diagram outlining the different Bounded Contexts and their explicit relationships.

Choose integration strategies. Different relationships between contexts require different strategies:

• Shared Kernel: Teams agree to share a subset of the model and code, requiring close coordination and frequent integration.
• Customer-Supplier: One team (customer) depends on another (supplier). The customer team influences the supplier's backlog, and automated acceptance tests validate the interface.
• Conformist: The downstream team (customer) simply conforms to the upstream team's (supplier's) model and language, having no influence on it.

Protect your model. When integrating with external or legacy systems, or when the supplier model is awkward, use an Anticorruption Layer. This layer acts as a translator between the two models, protecting your pure domain model from contamination. Alternatively, if integration benefits are minimal, choose Separate Ways, developing completely independently.

11. Distill the Core Domain from Generic Subdomains

In designing a large system, there are so many contributing components... that the essence of the domain model, the real business asset, can be obscured and neglected.

Identify the heart of the business. In large systems, the truly unique and valuable part of the domain model – the competitive advantage or core business logic – can get lost amidst generic components. Distillation is the process of separating this "Core Domain" from less critical parts.

Separate generic concerns. Many parts of a large system, while necessary, are not unique to the specific business domain. These "Generic Subdomains" (like user management, reporting frameworks, or general routing algorithms) can often be handled by off-the-shelf solutions or developed with less focus than the core.

Focus resources on the core. By explicitly identifying the Core Domain, development effort and skilled personnel can be concentrated there. The most talented modelers and developers should work on the core, applying the deepest insights and highest standards. Generic Subdomains can be handled more pragmatically, perhaps using standard solutions or less experienced teams.

Last updated: July 15, 2025