This is a chapter 7.3.14 from the EDGY Cookbook.
Domain-Driven Design (DDD)
Domain-Driven Design (DDD) is a strategic and tactical approach to software design and development that focuses on creating a deep connection between business needs and software solutions. At its core, DDD is about:
- Modeling the business domain in close collaboration with domain experts,
- Structuring the software around that model to reflect real-world complexity.
The domain is the starting point for modeling and design. Everything – language, models, systems – should reflect that business domain. This makes DDD a business-aligned approach to software, not just a technical one.
Domain-Driven Design (DDD) main concepts:
| DDD Concept | Description |
|---|---|
| Domain | The business area an enterprise operates in. E.g., logistics, insurance. |
| Subdomain | A specific functional part of the domain. E.g., claims handling, order management |
| Bounded Context | A well-defined business and language boundary where a specific model applies. |
| Ubiquitous Language | Shared language used by both business and tech, based on the business’s own terminology. |
These concepts helps us:
- Align software to real business capabilities of actual business operations
- Reflect how people actually work
- Ensure teams speak the same language
- Design around value-creating flows, not technical silos.
What? DDD is a methodology and mindset for building software that closely reflects the real-world business it serves. It helps teams align business knowledge, language, and systems, so that software delivers meaningful value.
Why? DDD helps you design software that thinks like the business:
- Closes the gap between business and technology
- Builds smarter software by modeling real business logic
- Reduces complexity through clear boundaries and ownership
- Enables scale by aligning architecture with business capabilities
- Accelerates delivery in complex domains (especially with microservices or modular platforms)
Domain-Driven Design (DDD) is a methodology and mindset for building software that closely reflects the real-world business it serves.
Key concepts of DDD:
- Domain: The specific sphere of knowledge or activity that the software is designed to model. It represents the business problem space.
- Subdomain: A distinct area of the overall business domain. It encapsulates specific business functions or responsibilities within the larger domain. There can be core-, supporting- and generic subdomains.
- Model: An abstraction that describes selected aspects of a domain and can be used to solve problems related to that domain.
- Entity: An object defined by its identity rather than its attributes. It has a unique identifier and a lifecycle.
- Value Object: An immutable object that is defined by its attributes. It has no identity and is interchangeable with other value objects with the same attributes.
- Aggregate: A cluster of domain objects that can be treated as a single unit. It ensures consistency within the boundary defined by the aggregate root.
- Aggregate Root: The main entity within an aggregate that controls access to the other entities and value objects in the aggregate.
- Domain Service: A stateless service that encapsulates domain logic which doesn’t naturally fit within an entity or value object.
- Domain Event: An event that signifies a change or occurrence within the domain that domain experts care about.
- Bounded Context: A boundary within which a particular domain model is defined and applicable. It ensures that the model remains consistent and unambiguous.
- Context Map: A visual representation of the relationships between different bounded contexts, illustrating how they interact and integrate.
- Repository: A mechanism for encapsulating storage, retrieval, and search behavior which emulates a collection of aggregates.
- Factory: A design pattern used to encapsulate the creation of complex objects or aggregates, ensuring that the creation process adheres to the domain’s invariants.
- Ubiquitous Language: A common language shared by all team members (developers, domain experts, etc.) that is used to connect all the activities of the team with the software. It ensures clear communication and understanding of the domain model.
7.3.14.1 – DDD Domains
A DDD “domain” is the same as the business domain the enterprise operates in: it’s the area of knowledge, activity, and value creation that software applications are meant to support. The domain is the subject area enterprise works in, and the focus area of the software applications (custom built or customised COTS).
The term “domain” in DDD is intentionally borrowed from business domain. It creates a shared understanding between business and tech. It keeps DDD grounded in real-world problems and goals, not just technical abstraction. That’s true to both business architecture and DDD thinking.
In DDD, the domain is just the business area your software is built to support, so the same business domains we talk about in strategy are the ones we model in our code.
Domain is a business area or problem space the software is built to support.
7.3.14.2 – DDD Subdomains
A smaller, distinct area within the broader domain, typically aligned with a business capability. Core domain is the most strategic and valuable part of the business domain where the enterprise’s competitive advantage lies. Business capabilities describe what the business needs to do, and DDD subdomains are the parts of the business we design software for to support those capabilities.
A subdomain is a focused part of the business that software needs to support.
A DDD subdomain is a business-aligned building block, it helps us organise software around what the business actually does.
- Subdomains help us break down complexity
- You can design each subdomain with its own bounded context
- Subdomains are often derived from business capabilities
This analogy aligns enterprise architecture with domain-driven software design.
- Business capabilities describe what the business does at a functional level
- DDD subdomains are the logical areas of responsibility within the domain that need to be modeled in software
- Therefore, “atomic” capabilities (at fine-grained level, e.g. the 3rd level) help identify and define subdomains, especially when mapping the enterprise into modular, aligned systems.
A subdomain bounds a business capability.
7.3.14.3 – Subdomains vs. Bounded Contexts in DDD
While subdomains pertain to the business domain, bounded contexts are a DDD concept that define clear boundaries within which a particular domain model is applicable.
A subdomain can be implemented within one or more bounded contexts, depending on the complexity and requirements. For instance, the “Order Management” subdomain might be divided into bounded contexts like “Order Creation,” “Order Fulfillment,” and “Order Tracking,” each with its own model and logic.
| Concept | Subdomain (Business Capability) | Bounded Context |
|---|---|---|
| Description | A logical area of business responsibility (what the business does) | A design boundary in the codebase where a particular domain model is valid |
| Focus | Business behavior (according to strategy) | Technical and linguistic consistency |
| Owner | Business stakeholders, architects | Software teams, domain experts, developers |
| Example | “Loan Origination” | LoanApplicationContext (with its own model, terms like “Preapproval”, “Score”, etc.) |
| Represents | A problem space: what needs solving | A solution space: how it’s solved |
Bounded contexts are typically designed around subdomains. A Bounded Context maps to one subdomain, or a tightly coupled group of subdomains.
Bounded Context is a design boundary where a particular domain model applies with its own language and logic.
7.3.14.4 – The Role of Applications in DDD
In DDD, applications are not the primary focus, but they do play a key role, especially when we move from domain modeling to implementation. Applications in DDD are the technical enablers of business capabilities, they run the logic defined in bounded contexts, which implement subdomains, which realize business capabilities.
In DDD, an application is:
- is a technical implementation that supports one or more bounded contexts,
- an executable system that implements the logic defined in a bounded context.
A bounded context defines a clear boundary where a specific domain model is valid. That model is realized in software, usually through one or more applications, services, or modules.
Applications support Business Capabilities:
- Business capabilities describe what the business must be able to do – to run the business
- Business capabilities map to subdomains in DDD.
- Subdomains are implemented inside bounded contexts.
- Bounded contexts are delivered as applications or services.
- Applications are where business capabilities become operational.
In DDD, applications are not the starting point, they are the result. They execute the business logic defined in a bounded context, which reflects a subdomain, which enables a business capability. Business capabilities are the starting point.
Bounded Contexts are implemented by applications.
7.3.14.5 – Separation of Concerns and DDD
In DDD bounded context, business rules belong to the domain model, not the application code. This separation keeps the (business) logic testable, reusable, and aligned with real business behavior. In DDD bounded context, business rules and business logic live in the Domain Layer, not in the application layer.
| Bounded Context layer | Responsibility |
|---|---|
| Domain Layer | Contains the core business rules and logic (e.g. policies, validations, decisions) |
| Application Layer | Orchestrates use cases: coordinates domain objects, doesn’t contain business rules |
| Infrastructure Layer | Deals with technical details (databases, APIs, messaging) |
7.3.14.6 – DDD and EA concept mapping
Mapping Domain-Driven Design (DDD) concepts to Enterprise Architecture (EA) concepts helps bridge the gap between business strategy and software implementation. This alignment ensures that software systems effectively support and enhance business capabilities. Here’s a table that outlines the correspondence between key DDD concepts and their EA counterparts:
| DDD Concept | EA Concept | Description |
|---|---|---|
| Domain | Business Domain | A high-level area of business activity, such as Finance, Sales, or Human Resources. |
| Subdomain | Business Capability | A specific function or competency within a business domain, like Payment or Invoicing within Finance. |
| Bounded Context | Application / System Boundary | Defines the boundary within which a particular domain model is applicable. In EA, this aligns with the scope of an application or system supporting specific business capabilities. |
| Entity | Business Object | An object with a distinct identity that persists over time, such as a Customer or Order. |
| Domain Service | Business Service | A stateless operation that encapsulates domain logic not naturally fitting within entities or value objects. |
| Domain Event | Business Event | An occurrence within the domain that is significant to the business, such as Order Placed or Payment Received. |
| Ubiquitous Language | Common Business Vocabulary | A shared language between business and IT stakeholders, ensuring clear communication and understanding of domain concepts. |
| Context Map | Integration Architecture Diagram | Visual representation of relationships and interactions between different bounded contexts or systems, highlighting integration points and dependencies. |
7.3.14.7 – DDD Subdomains & Business Capabilities
A subdomain in DDD is responsible for a particular business capability, encapsulating the related business logic and processes.
“Subdomains are finer-grained problem domains whose goal is to provide solutions for specific business capabilities.”
[Learning Domain-Driven Design, Aligning Software Architecture and Business Strategy, Khononov V., O’Reilly, 2022]
A business capability refers to an enterprise’s ability to perform a specific business function, such as payment processing, customer onboarding, or inventory management. In DDD, these capabilities are represented as subdomains, which are distinct areas of the business domain with their own specific logic and responsibilities.
DDD Subdomains can be identified based on the enterprise’s capability map.
- A capability map shows what the business needs to do.
- DDD subdomains show where software needs to support those things
Subdomains can be identified based on the enterprise’s Capability Map.
7.3.14.8 – Business capabilities are the starting point in DDD
Business capabilities:
- Define what the organization must be able to do to deliver value.
- They help identify the most important subdomains in Domain-Driven Design (DDD).
- They guide how teams, systems, and software should be structured.
- They connect strategy to operations and implementation, creating alignment.
It’s reasonable and practical to start with business capabilities, because they describe what truly matters: the work that delivers value. From there, we identify subdomains, define bounded contexts, and build the supporting systems through aligned teams.
7.3.14.9 – DDD concept mapping to business architecture
DDD Is Especially Useful For:
- Complex business domains
- Systems needing long-term maintainability
- Microservices or modular architectures
- Cross-functional collaboration (business + tech).
DDD helps the enterprise to model software around the business itself: aligned with business capabilities that deliver value. At the operational level: Teams build, run, and own the capability. They know what value it delivers and how it works end-to-end. At the development level: Developers implement logic that matches real business capability business rules and policies. Nothing is lost in translation. No guessing. No rework. DDD brings clarity to development teams, and flow to the enterprise. Teams build software that mirrors how the business works, adapts fast, and delivers real customer value – because teams are aligned, not just integrated, with the actual business behavior.
Domain-Driven Design (DDD) aligns systems with how the business actually works. It helps the enterprise go from features to flow, from silos to service, and from delivery to value.
7.3.14.10 – DDD and Capabilities
When starting with Domain-Driven Design (DDD) and aiming to build a business-aligned enterprise flow, the recommended order is to start with customer journeys and the business capabilities. These give the strategic and real-world anchors for everything that follows.
Business capabilities link everything to business value. Business capabilities define what the business needs to be able to do. This helps to identify related subdomains (Core, Supporting, Generic), and helps connect business strategy to domain-driven design.
Business capabilities act as a starting point for identifying Subdomains.
Business capabilities are essential for strategic planning and business architecture. They define what the business does, should do, or intends to do in alignment with strategic goals. They are high-level, technology-agnostic, and focused on value delivery.
Common Pitfall:
- The word “capability” is often used loosely across business and technical contexts, causing confusion. It is necessary to clarify whether you’re referring to business capabilities or system-level abilities.
When talking about capabilities, people often mean different things, which leads to confusion.
- Some refer to what the business is doing or must be able to do to deliver value: these are business capabilities.
- Others use the term to describe what a technical platform or application can do, such as application functions or features. It’s a common tendency to apply the word “capability” in a technical context, even when more accurate terms like system responsibilities, services, or functions would be clearer.
The term “capability “is often used loosely across business and technical contexts, causing confusion.
Without clarification, “capability” becomes a vague catch-all that mixes strategic, business, and technical concerns. This leads to misalignment between business and IT, especially in architecture, planning, and team conversations. Being intentional and consistent in using terms like business capability and system capability (a.k.a. platform capability or technology capability) helps create shared understanding.
Terms are introduced in the table below.
| Term | Definition | Used By | Example | Purpose / Use | Notes |
|---|---|---|---|---|---|
| Business Capability | What the business must be able to do to deliver value and meet strategic goals, and indirectly: to support customer needs | Executives, business architects, product owners | “Manage Orders”, “Handle Inquiries” | Strategic planning, capability mapping, DDD subdomain identification | Stable, tech-agnostic, not a process or system |
| System Capability | What a system or service is responsible for doing to support business needs | Architects, platform teams, technical leads | “Generate Invoice”, “Process Order Data” | Service boundaries, system design, team ownership, bounded contexts | Supports business capabilities; mid-level technical abstraction |
| Application Function | Backend operation or use case implemented in a system | Developers, solution architects | “Validate Payment”, “Calculate Tax” | API/service implementation, technical decomposition | Often part of a bounded context |
| Application Feature | User-facing functionality that exposes system behavior | Product managers, UX designers, end-users | “Submit Report”, “Download Invoice” | UI design, roadmap planning, user experience | May span multiple capabilities and functions |
Key differences between business capabilities and system capabilities are shown in the table below.
| Aspect | Business Capability | System Capability |
|---|---|---|
| Focus | What the business does | What a system can do |
| Level | Strategic / conceptual / business | Operational / technical / |
| Stability | More stable over time | Can change as tech evolves |
| Audience | Business leaders, strategists, architects | Developers |
| Example | “Manage Customer Data” | “Update customer address in CRM system” |
7.3.14.11 – Flow of Actions: Capability Map → DDD → Applications
Start from business needs (capabilities), organize them using DDD (subdomains + bounded contexts), and implement them as focused applications.
- Start with the Capability Map
- Identify what the business needs to do
- Define Subdomains – based on business capabilities
- Group capabilities into logical business areas (subdomains) based on purpose and complexity.
- Identify Bounded Contexts
- Set clear boundaries for each subdomain – define the terms, logic, and rules used inside them.
- Design Applications
- Build or structure applications (e.g. microservices, modules) around those bounded contexts.
- Assign Teams
- Align teams with the bounded contexts and applications they own and evolve.
7.3.14.11 – How DDD Relates to the Flow of Operational Business and Development
Central to applying Domain-Driven Design (DDD) not just as a modeling tool, but as a way to improve how business and development flow together. DDD isn’t just a software technique, it directly supports the flow of operational business and connects to how development delivers value.
1. DDD reflects how the business actually works
- Domains and subdomains
- mirror real business functions and flows
- reflect real business areas: business domains
- Bounded contexts
- define clear boundaries where these operations are modeled, owned, and executed.
- match how responsibility is split across teams or departments.
2. DDD enables flow in development
- Each subdomain becomes a clear unit of work, linked to business outcomes.
- Bounded contexts become team-aligned modules that can be built, tested, and delivered independently.
- Developers know exactly which business capability they’re supporting
- Development is organized around bounded contexts, which map to teams, systems, and services
- This matches Team Topologies thinking: stream-aligned teams own specific value flows
- Each team works with autonomy, clarity, and a shared domain language
- Less friction, faster delivery, fewer handovers – better flow of change.
3. DDD supports end-to-end value delivery
- When designed around domains:
- We can trace a customer journey to a business capability to a bounded context to a team/system
- This helps model the overall flow: the Enterprise Flow:
- From need → to capability → to implementation → to customer value
- Both business operations and development are aligned around continuous value flow.
DDD aligns business flow with development flow, so value moves smoothly from customer need to working software.
Domain-Driven Design (DDD) aligns operational business flow with development flow.
— Eero Hosiaisluoma