A subdomain is a distinct part of a business domain, shaped around related concepts and a coherent purpose. Larger domains can contain several subdomains; a fulfillment domain, for example, might contain availability, last mile, warehousing, and logistics. The boundary is useful when it gives a team an area it can understand and change without repeatedly coordinating with other teams. section 9.5 section 6.1.2
Look for concepts that tend to change together. A travel company adding loyalty levels may need to change loyalty accounts, points, and rewards. Keeping those concepts in one subdomain could let one team make the change in one codebase; splitting them across three subdomains could require three teams to coordinate. Cohesion can also give the team a lasting purpose, such as rewarding loyalty and increasing customer lifetime value. section 9.1
There is rarely one perfect boundary. Concepts can be related in several ways, and the best grouping depends partly on the changes the business expects. A boundary that makes one kind of change easy may make another span several subdomains. Explore alternatives rather than treating an organizational chart or a process diagram as the answer. section 9.2.2 section 9.5
To explore candidate subdomains collaboratively:
- Map a real customer journey with EventStorming, then group sequences of events that seem to belong together. Compare different ways of splitting the timeline, including boundaries at different scopes. section 4.4.2 section 9.4.2
- Give each candidate a short purpose statement. Ask whether its events fit that purpose, whether its concepts have changed or will change together, and whether one team could reasonably own them. section 9.4.5
- Check whether a journey truly belongs to one subdomain, delegates some rules to others, or combines several subdomains with different purposes. A process step is a clue, not proof of a boundary. section 9.4.4
When a journey crosses boundaries
An onboarding journey might have an Onboarding subdomain that manages the process while delegating identity verification or wallet rules. If its steps involve substantially different concepts also used elsewhere, there may be no Onboarding subdomain at all. Choose based on the concepts and their purposes, not merely the journey’s name. section 9.4.4
Use the EventStorm diagram to compare a larger domain boundary with the subdomains inside it while discussing which event sequences belong together. section 9.4.2
A candidate subdomain is also a candidate area for a dedicated value stream, team ownership, and software that can change independently. Keep its complexity within what a team can handle; split it if the cognitive load becomes too high. Related subdomains can still be grouped into a larger domain where teams need to cooperate on higher-level outcomes. section 1.2 section 11.1.5 section 6.1.2
Use subdomains to make investment decisions, not just to draw an architecture. A Core Domain Chart can help compare their differentiation and complexity and discuss where to modernize first. Revisit both boundaries and priorities as knowledge, business strategy, and the subdomains themselves evolve. section 10.0 section 10.2.4 section 10.2.3


