The previous parts introduced events, policies, commands, and aggregates as the building blocks of domain flow. Translating those flows into a system structure that can be built and maintained requires a different set of concepts. The flows tell us what happens. The structure tells us who owns what, where consistency is enforced, and how teams coordinate.
Defining clear boundaries, both technical and organizational, keeps a system maintainable and scalable over time. Domain-Driven Design (DDD) provides three structural concepts for this purpose.
| Concept | Purpose |
|---|---|
| Bounded Contexts | Organize aggregates into meaningful, consistent groupings |
| Subdomains | Understand the business problem space at a broader, functional level |
| Domains | Structure the entire system around cohesive business capabilities |
Structure is the sociotechnical glue that binds a system’s design to the reality of the business’s own organization. Once a system grows beyond a single team, structure determines whether teams can work independently or are constantly blocked by shared ownership and unclear boundaries.
A system’s design should reflect natural communication paths within the organization. This is Conway’s Law in practice. Large systems span multiple teams, departments, and lines of business. They need a shared language to describe ownership, coordination, and boundaries. Aggregates, bounded contexts, and subdomains provide that language. They align software with how the business actually works.
Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.
Below is a simple example of how even a casual Event Storming session, anchored in open, real-time conversations, can naturally evolve into meaningful structures without relying on heavyweight process.
Portfolio and Wire Transfer hints at deeper coordination needs. This is where the importance of structure begins to take shape.In a large organization, hundreds or even thousands of aggregates may interact with each other. The next step is to organize those aggregates into bounded contexts. Aggregates model local consistency. Bounded contexts define ownership, responsibility, and boundaries across the broader system.
Bounded Contexts: Architecting for Communication
A bounded context is a well-defined scope in which a particular domain model is valid. It establishes clear language and ownership within that scope.
Aggregates within a bounded context communicate through aggregate events. These events capture internal state changes and are not published externally. Aggregates across bounded contexts communicate through domain events. Domain events represent significant business occurrences and are explicitly published for external consumers. Strong consistency is maintained within an aggregate. Communication between aggregates, even within the same bounded context, often relies on asynchronous messaging for eventual consistency.
For example, in a stock trading platform, we might define multiple bounded contexts.
| Bounded Context | Purpose | Domain Concepts |
|---|---|---|
| Portfolio Management | Tracks portfolios and asset holdings | Portfolio (Aggregate) |
| Order Execution | Handles trade execution and settlement | Order (Aggregate) |
| Market Data | Provides real-time stock quotes and pricing | Quote (Read Model), Stock (External Entity) |
| Risk Management | Monitors compliance and risk exposure | RiskRule (Policy), Alert (Policy + Read Model) |
Each bounded context has a clear purpose and well-defined ownership. Teams can develop, deploy, and scale each context independently because the contracts between them are explicit.
Bounded contexts emerge naturally during Event Storming sessions. Certain aggregates interact more frequently, forming natural clusters. Different parts of the system use different terminology, signalling separate contexts. Some areas require strong consistency. Others can tolerate delays. Specific teams have already mastered specific domain concepts. These patterns help define the bounded contexts that shape the system’s architecture.
Subdomains: Aligning Teams and Capabilities
Bounded contexts define technical ownership. Subdomains help us understand the problem space at a business level. A subdomain is a business capability within a larger system.
In financial services, we might identify the following subdomains.
| Subdomain | Description |
|---|---|
| Retail Banking | Handles everyday banking transactions |
| Investment Management | Manages portfolios and financial assets |
| Risk and Compliance | Ensures legal and regulatory compliance |
| Market Trading | Facilitates buying and selling of securities |
Each subdomain contains multiple bounded contexts that solve specific business problems. Within the Market Trading subdomain, for example, we may assign the Portfolio Management, Order Execution, and Market Data bounded contexts.
Subdomains bridge business strategy and technical design. To identify them, look for distinct business functions that operate independently, observe where different user groups interact with the system, and note where different regulations, policies, or compliance rules apply.
Domains: The Operating System of the Business
At the highest level, a domain represents the entire business problem space. A stock trading platform is just one domain within financial services.
Domains define the big picture of the business. They establish the scope of what the system needs to cover and guide how teams should be structured around capabilities.
Domains contain multiple subdomains. Subdomains contain multiple bounded contexts.
Financial Services (Domain)
│
├── Market Trading (Subdomain)
│ ├── Portfolio Management (Bounded Context)
│ ├── Order Execution (Bounded Context)
│ ├── Market Data (Bounded Context)
│
├── Retail Banking (Subdomain)
│ ├── Account Management (Bounded Context)
│ ├── Loan Processing (Bounded Context)
│ ├── Fraud Detection (Bounded Context)
│
├── Risk and Compliance (Subdomain)
│ ├── Risk Monitoring (Bounded Context)
│ ├── Audit and Reporting (Bounded Context)
│ ├── Regulatory Compliance (Bounded Context)
This hierarchy provides a way to reason about structure during and after an Event Storming session. It also lays the foundation for code scaffolding that aligns with natural business domain boundaries. Software mirrors the business. Teams work in parallel without stepping on each other. Different parts of the system decouple for independent scaling and evolution.
Summary
Over the last three parts we have assembled a vocabulary for structuring software around the business it serves.
- Events tell the truth about what happened.
- Policies model reactions and side effects.
- Commands express intent.
- Aggregates define transactional boundaries and protect consistency.
- Bounded contexts define ownership and communication boundaries.
- Subdomains align technical structure with business capabilities.
These are the building blocks of Domain-Driven Design. They are not the only way to organize an event-sourced system, but for systems that require strict invariant ownership, auditable state transitions, and explicit consistency boundaries, they are the most durable foundation available. The techniques in this series give teams a shared vocabulary for designing those systems before writing code.