Context Mapping

Making the relationships between bounded contexts, and the teams that own them, explicit, so that integration between separate models is a deliberate design choice rather than an accident. Domain-Driven Design names the relationship types (shared kernel, customer/supplier, conformist, anti-corruption layer, published language, separate ways); Team Topologies names the same integration at the team level (collaboration, x-as-a-service, facilitating). A context map is the strategic picture of who depends on whom, in which direction, and how.

Composed Of

• Bounded Context — the units being mapped; each owns one model and one language.
• Conway's Law — context boundaries and team boundaries track each other, so the map is as much organizational as technical.
• Team API — the explicit interface a context or team exposes, which is what makes a stable, service-style relationship possible.
• Team Interaction Modes — the team-level vocabulary (collaboration, x-as-a-service, facilitating) that mirrors DDD's context relationships.

Why it Matters

Multiple models must integrate, and the dangerous case is integrating them implicitly, by assuming a shared meaning that does not actually hold. Naming the relationship makes the dependency, its direction, and its cost visible, so teams can choose protective translation (an anti-corruption layer) where models genuinely differ, and lightweight consumption (x-as-a-service) where an interface is stable.

Signals

• The team can draw who depends on whom and in which mode, and the upstream/downstream direction is acknowledged.
• Integrations have an explicit, owned interface or translation layer rather than a shared database or model.
• Failure signal: contexts share internals implicitly, so a change upstream silently breaks downstream.

Risks

A map drawn once and never updated; treating an unstable, still-changing context as if it were a stable service; collaboration that is never time-boxed and erodes both contexts' ownership.