Core Building Blocks
AGGREGATE
A cluster of associated objects treated as a unit for the purpose of data changes. External references are restricted to one member, the root entity, through which all external interactions must pass. A set of consistency rules applies within the AGGREGATE’s boundaries.
Why it matters: Aggregates enforce invariants and define transactional boundaries, ensuring data integrity across the domain model.
ASSERTION
A statement about the correct state of a program at some point, independent of its implementation. Typically, specifies either the result of an operation or an invariant of a design element.
Why it matters: Assertions serve as executable documentation and help catch violations of domain invariants early in development.
BOUNDED CONTEXT
The delimited applicability of a particular model. A BOUNDED CONTEXT gives team members a clear and shared understanding of what has to be consistent and what can develop independently.
Why it matters: Explicitly defining BOUNDED CONTEXTS helps prevent model confusion across different parts of a complex system and clarifies integration boundaries.
CONCEPTUAL CONTOUR
An underlying consistency of the model itself that, when reflected in the design, helps accommodate change more naturally by revealing the natural boundaries and relationships within the domain.
Why it matters: Recognizing conceptual contours allows designers to align the model with domain realities rather than imposed technical structures.
CONTEXT MAP
A representation of the BOUNDED CONTEXTS involved in a project and the actual relationships between them, such as upstream/downstream, customer/supplier, or anti-corruption layers.
Why it matters: A CONTEXT MAP serves as a strategic tool for understanding how different parts of your system interact and where translation layers are needed.
CORE DOMAIN
The distinctive part of the model, central to the user’s goals, that differentiates the application and makes it valuable. Everything else should be delegated or outsourced.
Why it matters: Focusing engineering effort on the CORE DOMAIN maximizes business value and avoids investing in generic capabilities that competitors can easily replicate.
ENTITY
An object fundamentally defined not by its attributes, but by a thread of continuity and identity. Two entities may have identical attributes but remain distinct due to their unique identities.
Why it matters: Entities model the continuity and traceability required by domain experts, such as customer accounts or order histories.
FACTORY
A mechanism for encapsulating complex creation logic and abstracting the type of a created object. Factories help clients focus on what is needed, not how it is built.
Why it matters: Factories prevent clients from becoming entangled in the construction details of complex objects while preserving object integrity.
INTENTION-REVEALING INTERFACE
A design in which the names of classes, methods, and other elements clearly convey both the developer’s purpose in creating them and their value to a client developer.
Why it matters: Intention-revealing interfaces reduce cognitive load and communication overhead by making the domain model self-documenting.
LAYERED ARCHITECTURE
A technique for separating concerns in a software system, typically isolating the domain layer from infrastructure, presentation, and application coordination concerns.
Why it matters: Proper separation ensures that domain logic remains independent of technical concerns and can evolve without ripple effects across the system.
MODEL-DRIVEN DESIGN
A design in which software elements correspond closely to model elements, and a process of codeveloping the model and implementation so they remain aligned throughout the project lifecycle.
Why it matters: Model-driven design prevents drift between conceptual understanding and implementation, preserving the value of collaborative modeling efforts.
MODULE
A packaging construct that groups related concepts and functionality together. Unlike BOUNDED CONTEXTS, MODULES are implementation artifacts used to organize code, and they don’t necessarily correspond to one conceptual model. A single BOUNDED CONTEXT may span multiple MODULES, and a MODULE may contain elements from multiple models if they are closely related in the codebase.
Why it matters: MODULES reduce cognitive load by grouping related functionality, making the codebase easier to navigate and maintain. They help communicate architectural decisions through their organization.
REPOSITORY
A mechanism for encapsulating storage, retrieval, and search behavior that emulates a collection of objects. Repositories provide domain-focused access to aggregates without exposing persistence details.
Why it matters: Repositories decouple the domain layer from infrastructure concerns and provide a natural, collection-like interface for domain experts to reason about.
SERVICE
A standalone operation offered through an interface, with no encapsulated state. Services represent domain activities or transformations that don’t naturally belong to an ENTITY or VALUE OBJECT.
Why it matters: Service objects allow the model to express domain concepts that involve interactions between multiple entities or value objects without forcing them into inappropriate hierarchies.
UBIQUITOUS LANGUAGE
A language structured around the domain model and used by all team members to connect all activities, from discussion to code, with the software implementation.
Why it matters: A shared Ubiquitous Language eliminates ambiguity, improves communication, and ensures that the code accurately reflects domain understanding.
VALUE OBJECT
An object describing some characteristic or attribute of the domain that carries no concept of identity. Two value objects with identical attributes are considered equivalent.
Why it matters: Value objects capture domain concepts precisely without introducing unnecessary identity tracking, leading to simpler and more robust designs.
General Concepts
deep model
An incisive expression of the primary concerns and essential knowledge of domain experts. A deep model sloughs off superficial aspects of the domain and naive interpretations to reveal the core domain principles.
Why it matters: A deep model enables more accurate predictions, better decisions, and higher-quality software by capturing domain essence rather than surface phenomena.
distillation
A process of separating the components of a complex system to extract and highlight the core essence. In DDD, this means identifying and isolating the CORE DOMAIN while delegating or simplifying generic functionality.
Why it matters: Distillation reduces complexity by directing effort where it creates the most business value and eliminates unnecessary coupling to non-core concerns.
stateless
A property of a design element that allows clients to use its operations without concern for history. Stateless elements may interact with globally accessible information or cause side effects, but hold no private state that affects their behavior.
Why it matters: Stateless components are simpler to reason about, test, and scale, particularly in distributed systems where state management adds complexity.
supple design
A design that empowers client developers to express domain intent clearly and flexibly, while enabling implementers to mold and reshape the design as understanding deepens. Supple designs leverage a deep model to support both expressiveness and malleability.
Why it matters: Supple designs evolve naturally with domain understanding, reducing the cost of change and maintaining alignment between model and implementation over time.
Domain Vision Statement
A short document (typically one page) that captures the essence of the domain, the problem it solves, and the scope of the software system. It serves as a high-level overview that helps everyone on the team understand what the system is about, who will use it, and why it matters.
A well-crafted Domain Vision Statement includes:
- The name of the system
- The problem domain it addresses
- The primary users and stakeholders
- The core capabilities or features
- The business goals it supports
Why it matters: A Domain Vision Statement acts as a compass for the project, helping to align the team’s understanding and focus development efforts on delivering maximum business value.