Context Mapping Strategies
Context mapping documents the relationships between bounded contexts — shared kernel, customer-supplier, conformist — so that the integration patterns are explicit and the teams know who depends.
Definition
Context mapping is the practice of identifying and documenting the relationships between bounded contexts — the translation patterns (shared kernel, customer-supplier, conformist, anti-corruption layer, open host service, published language) — so that integration decisions are explicit and the direction of dependency is visible.
Context and scope
Applied in multi-team domain-driven design, post-monolith decomposition, and any organization where several bounded contexts must integrate and the integration pattern is a decision, not an accident.
Common misconceptions
- A context map is a deployment diagram — it maps model relationships, not deployments; a deployment is a separate concern
- Shared kernel is the default integration — it is the most coupling; it should be rare, chosen when the cost of translation exceeds the cost of coupling
Anti-patterns
- Drawing a context map and never updating it, so it documents the original architecture and misleads every later decision
- Choosing conformist by default, making every downstream context a passive consumer of upstream model decisions it cannot influence
Related concepts
Authoritative source
What it is
Context mapping is the practice of identifying and documenting the relationships between bounded contexts — the translation patterns (shared kernel, customer-supplier, conformist, anti-corruption layer, open host service, published language) — so that integration decisions are explicit and the direction of dependency is visible. Applied in multi-team domain-driven design, post-monolith decomposition, and any organization where several bounded contexts must integrate and the integration pattern is a decision, not an accident. The organizing principle is which decisions are hard to reverse and should be made once, versus which are easy to reverse and should be deferred.
How it works
Boundaries are drawn along axes of change: things that change together are colocated, things that change independently are separated by interfaces whose contracts are explicit and versioned. Dependencies point toward stability — domain logic depends on abstractions, infrastructure depends on domain, never the reverse. The structure makes the system’s intent legible without reading every module.
When to choose and pitfalls
Choose this structure when the system will outlive its first deployment and face requirements you cannot now predict. The pitfall is premature abstraction — adding indirection for a flexibility that never materializes, paying its complexity cost forever. The opposite pitfall is entangling concerns that later need to separate, forcing a rewrite instead of a refactor.