A domain is an area of business activity and knowledge. It groups related subdomains whose concepts contribute to a shared higher-level purpose. That grouping helps teams working in different value streams stay aligned: their work may be distinct, but the business outcome is not entirely independent. section 6.1.2
Domain boundaries are both business and architectural choices. Cohesive subdomains give teams clearer ownership and can reduce dependencies in software. The aim is not to eliminate every dependency at any cost. Ask which concepts tend to change together, where coordination is unavoidable, and whether a proposed boundary helps teams deliver the intended outcome. There is rarely one perfect decomposition; boundaries should be revisited as the business changes. section 9.0 section 9.5
A fulfillment domain
A fulfillment domain can contain availability, last mile, warehousing, and logistics subdomains, each with a dedicated value stream. The domain gives those streams a shared business context without requiring one team to own all four. section 6.1.2
Domains can also be nested. A small domain may fit one team; a group of related domains may require multiple teams, and a larger grouping may require multiple groups of teams. Choose the number and size of levels to fit the organization’s complexity, not a fixed template. Naming matters, too: at an airline, stakeholders used business terminology to identify domains such as Offer/Ordering and Check-in & Boarding, then separated concerns that teams could largely own independently while keeping related work aligned. section 6.1.2 section 9.3.4
To explore a boundary with stakeholders:
- Map the business journey as an EventStorm and identify pivotal events, transitions, and handovers. section 9.4.2
- Group sequences of events that seem to belong together. Sketch boundaries at more than one scope; breakout groups can produce alternatives to compare. section 9.4.2
- Test each grouping against concept cohesion, likely changes, team ownership, and the cost of dependencies. Refine it when greater detail challenges the initial assumptions. section 9.0 section 9.5
The EventStorm visualization makes it easier to discuss a domain containing multiple subdomains and to compare possible boundary scopes. section 9.4.2
A domain can also focus data ownership. For example, in finance, choosing individual accounts rather than all accounts limits scope and points toward the people who understand the relevant data sources, rules, and history. Define only the boundaries needed for the next decision or improvement; ownership and architecture can evolve together. section 14.2.1 section 6.5
