A system boundary separates a coherent area of business behavior from other areas. In domain modeling, domains and subdomains provide candidate boundaries for teams and software. A useful boundary groups concepts that tend to change together, so a new feature is less likely to require coordinated changes across several teams or codebases. The goal is not to eliminate every dependency, but to decide which dependencies are worth avoiding and which are too costly to remove. section 9.5 section 9.0
Boundaries serve organizational goals; there is no universally correct partition. The same concepts may be grouped by different characteristics, and each grouping favors different kinds of change. A boundary that supports independent product decisions might duplicate capabilities or make the experience across products less consistent. A shared capability might improve reuse while creating new dependencies. Compare plausible models against the outcomes sought rather than adopting the first tidy diagram. section 9.2.1 section 9.2.4
A boundary changes with the goal
The BBC initially aligned high-level domains with services such as news, sport, weather, and education. Those services had developed independently, but similar features were implemented repeatedly and the experience across services was not as consistent as it could be. Its WebCore initiative identified horizontal domains including Articles, Search, and Topics to support a different balance of shared capabilities and product independence. section 9.2.5
To explore boundaries collaboratively, use EventStorming to map business events and journeys, then partition the map into candidate domains and subdomains. Include domain experts alongside product, design, and software perspectives so that assumptions and terminology can be challenged. Treat the resulting partitions as proposals: investigate promising areas in more focused workshops and test them with other perspectives, such as Domain Message Flow Modeling and Team Topologies. section 1.2.1 section 7.1.4
A visual starting point for grouping parts of an EventStorming timeline into candidate domains and subdomains—not a rule that every process step needs its own boundary. section 1.2.1 section 9.4.4
Questions that help test a candidate boundary:
- Which concepts and business rules are likely to change together? Would a typical feature require several teams to coordinate, integrate, and test changes? section 9.0 section 1.2.1
- Does domain language change across contexts? The same person may be a Lead in Marketing, a Rider in Journeys, and a Reporter in Maintenance; the different meanings can signal distinct subdomains. section 9.3.2
- Is a journey itself a subdomain, a subdomain that delegates some work, or a process composed of several subdomains? Do not equate a step on a timeline with a boundary automatically. section 9.4.4
- What would centralization save, and what new dependency would it create for consumers? Test whether the owning team could respond to their needs. section 9.3.2
Grouping related but distinct work
In an airline modernization effort, EventStorming helped identify domains including Offer/Ordering, Redemption and Loyalty, Check-in & Boarding, and Trip Management. Offer/Ordering contained separate subdomains for offers, booking, and fulfillment: each could largely be owned independently, while their remaining coupling justified considering them together as one domain. The names came from terminology developed with stakeholders, not a generic technical taxonomy. section 9.3.4
Keep the design provisional. A high-level boundary can fail when detailed modeling reveals hidden dependencies; a subdomain can also grow beyond one team. Revisit domain, team, and software boundaries as those conditions emerge. Good boundaries help reduce coupling, but structure alone cannot substitute for sound priorities, sustainable practices, and learning. section 9.2.6 section 9.2.8 section 9.2.7
