33 lines
3.2 KiB
Markdown
33 lines
3.2 KiB
Markdown
# 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](../../../../AGENTS.md#development-data-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.
|