Business Domain Boundary
A division of the business into areas with distinct language, ownership and rates of change, used as the primary input to system and team boundaries.
Technical boundaries drawn without reference to the business produce systems that fragment on every business change. Boundaries drawn along business domains hold, because the domains themselves are stable.
The signals that mark a boundary, in order of reliability:
Language divergence. Where the same word means genuinely different things — "customer" in billing, support and marketing have different attributes, lifecycles and owners — there is a boundary. This is the strongest and cheapest signal available, and it comes free from listening to how people speak.
Ownership. Where a different part of the business is accountable for the outcome.
Rate and reason for change. Areas that change for different reasons at different rates should be separable.
Regulatory scope. A domain subject to specific regulation benefits from a boundary that contains it, because the compliance burden then does not spread.
The architectural consequence: these boundaries become candidates for bounded contexts, service boundaries and team boundaries — and Conway's Law means that if teams are not aligned to them, the system will not be either, whatever the design says.
The counter-signal to weigh: a boundary requiring a synchronous call on every transaction has created temporal coupling. Either the boundary is wrong, or the interaction must be redesigned as asynchronous.