In this chapter
6.1 Separate what changes for different reasons
A business domain owns the meaning and rules of its work. A shared platform capability provides a repeatable service used by several domains. Technology implements either responsibility. Infrastructure hosts the implementation. Keeping those categories distinct prevents the architecture from becoming an inventory organized around product names. In the fictional institution, request management owns request versions and transitions. Fulfilment owns execution facts. Finance owns reconciliation and reporting definitions. Shared identity establishes authenticated actors; it does not decide whether a particular actor may approve a particular request. That authorization remains connected to the domain policy.
6.2 Responsibility boundaries
| Boundary | Owns | Must not silently own |
|---|---|---|
| Request domain | Request lifecycle and approved version | Execution evidence created by operations |
| Fulfilment domain | Actions performed and operational exceptions | Changes to a finance approval |
| Finance domain | Reconciliation rules and report definitions | Undocumented correction of source facts |
| Shared platform | Identity integration, delivery, common telemetry | All business decisions |
6.3 Share capabilities without creating a bottleneck
Shared does not mean centrally approving every small change. Define a service contract: what the capability provides, who operates it, how consumers gain access and what changes require coordination. A notification capability accepts a delivery intention; it must not become the authority for whether the originating decision was valid. For a small team, these responsibilities can exist as modules and assigned duties within one deployment. The diagram does not mandate six independent services. Separate deployment requires evidence of a need such as independent ownership, isolation or release cadence, together with a support model.
6.4 Federation needs enforceable agreements
Common rules cover identity claims, audit identifiers, contract compatibility and operational handover. Domain owners retain specific policy decisions within those rules. Exceptions require an owner and review trigger. A central architecture function should resolve cross-domain conflicts without taking over every domain’s implementation choices. When two modules need the same fact, name its authority. A report may retain a projection of an approval, but it must identify the authoritative version and freshness. Directly editing that projection to “fix the number” would bypass the owner and break traceability.
6.5 Required artifacts
- Domain boundary map with authoritative facts and owners.
- Shared capability catalog with consumer and support contracts.
- Cross-boundary dependencies and compatibility expectations.
- Rules for ownership disputes, exceptions and decomposition.
The review gate is a walkthrough of an amendment crossing request, fulfilment and finance boundaries. If each owner can explain what changes, what remains stable and how a conflict is resolved, the model is useful enough to guide design.