A domain is a distinct area of platform responsibility with concepts, priorities, and boundaries shaped by a coherent user experience. Domain-driven design helps teams divide an engineering platform into independently operated areas without making the experience feel fragmented. section 1.3.2
Use domain boundaries to organize platform work around user-facing responsibilities rather than traditional IT functions:
- Give each domain team its own backlog and priorities so it can operate independently. section 1.3.2
- Coordinate dependencies mainly through subdomain product owners and domain-level architects, not through individual engineers. section 1.3.2
- Treat frequent requests between developers on different teams as a smell indicating that a boundary, interface, or responsibility needs attention. section 1.3.2
- Validate domains continuously through loose coupling, service-interface-first design, preserved change boundaries, shared language, release independence, and accessible domain events. section 3.5.4
Platform team boundary
If developers routinely need Slack, email, or meetings to resolve work with another domain team, the platform boundary is creating coordination friction rather than enabling independent delivery. section 1.3.2
Figure 1.4 Eight principal product domains within an engineering platform. The numbers by the domain indicate an underlying dependency ordering when launching a new platform.
Use the platform-domain dependency figure to inspect how principal product domains relate when launching an engineering platform. section 1.3.2
Figure 3.8 Engineering platform product domains
Use the domain map to connect each platform product domain with the metrics needed to assess progress and improvement. section 3.5.4
