# 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.