3.2 KiB
Bounded Contexts and Context Mapping
A bounded context defines where a domain model and its language apply. It is not automatically a microservice, package, or team-sized deployment.
Find a real boundary
Look for differing business meanings, rules, ownership, or change lifecycles. Check concrete scenarios and existing ADRs. A single context may be correct; excessive translation between closely related concepts can signal an unnecessary split.
For a requested context map, show the relevant contexts, ownership, upstream/downstream relationships, shared contracts, and any translation. Avoid mapping unrelated systems just to complete a catalog.
Choose the relationship
| Pattern | Useful when | Cost to make explicit |
|---|---|---|
| Shared kernel | Closely collaborating owners genuinely share a small model | Coordinated changes and tests |
| Customer–supplier | The upstream team can accommodate downstream needs | Planning and contract dependency |
| Conformist | Accepting the upstream model is cheaper and safe for this use case | Coupling to upstream semantics |
| Anti-corruption layer | Foreign semantics would distort local business rules | Translation and its tests |
| Open host service / published language | Several consumers need a documented shared contract | Contract ownership and actual external obligations |
| Separate ways | Integration costs more than limited duplication | Separate implementations and knowledge |
| Partnership | Models must evolve together | Ongoing coordination |
| Big ball of mud | Existing entanglement needs to be named during an assessment | A diagnosis, not a target design |
Translation can live in an existing adapter or mapper; it does not require a facade/adapter/translator class hierarchy. Validate untrusted external data even when adopting the upstream model directly.
Changes and external constraints
Preserve actual external contracts that the task cannot replace. Legacy coexistence patterns apply to a genuinely external system that must remain available, not to this application's disposable development model.
For internal model changes, follow the development lifecycle: replace obsolete schemas/contracts, update callers and tests together, and reseed rather than introducing compatibility paths.
Explain a proposed split or merge through its effect on language, invariant ownership, coupling, and coordination. Do not reorganize teams, deploy services, or modify contracts merely because a map was requested.