A system boundary separates a platform domain’s responsibilities from those of its consumers and other domains. Its practical test is the experience at the edge: can someone use a capability when needed, without opening a ticket or contacting the team that owns it? A useful boundary lets teams own their backlogs and release their capabilities independently while keeping the consumer experience smooth. section 2.3.4 section 1.3.2
Do not draw boundaries solely along traditional IT functions. A division that looks tidy on an organization chart may still force developers to coordinate every change across teams. Repeated requests, meetings, or messages just to use another team’s capability are a signal to inspect the boundary, measure the friction, and adjust it. section 1.3.2 section 6.1
Check a proposed boundary from both sides:
- Consumer: Can users access the capability through an API, UI, or documented standard and manage their own use without a ticket? section 2.3.4 section 3.1.1
- Owner: Can the team complete work and deploy its capability without fine-grained coordination with dependent teams? section 2.3.4
- Product: Do the boundaries support internal products that can change over time, rather than preserving responsibilities that obstruct delivery? section 2.0 section 1.3.2
Grow the boundary before splitting the team
During initial platform integration and minimum viable platform development, one team can manage boundaries between subdomains. As demand for platform features grows, it can hand a subdomain to another team if the parts already have a low-friction, loosely coupled interface. The receiving team then needs the same independent, self-service relationship with other platform teams that developers expect from the platform. section 6.1 section 9.0
Figure 2.14 Start by defining the primary boundary experience, which is our platform customers. Then, figure out where the underlying changes or capabilities lie and when more than one team is involved, does an effective boundary experience exist between them?
Use the boundary diagram to trace a capability from the platform customer to the teams implementing it, then check the experience wherever work crosses teams. section 2.3.4
