// Domain-Driven Design · 03
Context Mapping
Map who depends on whom between contexts, and how they translate.
How it fits together
- Identity publishes / notifies Sales (U→D conformist)
- Legacy ERP publishes / notifies Sales (U→D via ACL)
- Sales replicates / copies Billing (shared kernel)
- Sales publishes / notifies Shipping (cust./supplier)
Spot it
- An upstream change breaks three other teams
- Nobody owns the shared Customer model
- Integration surprises in every release
It costs
A map is a snapshot of code and team politics; it goes stale unless revisited.
Go deeperThe full explanation and what to ask for · 1 min readExpandCollapse
A context map shows bounded contexts and the relationships between them. On each link one side is upstream (its model and changes flow out) and the other downstream (affected by them). The pattern on the link says how the downstream copes.
Team patterns: partnership (two teams plan and release together), shared kernel (a small model both own, changed only by agreement), customer–supplier (downstream needs feed the upstream backlog), conformist (downstream adopts the upstream model as is), separate ways (no integration, duplicate instead). Integration patterns: open host service with a published language (a documented, versioned API or event schema) upstream, and an anti-corruption layer downstream.
Draw the map as it is, not as you wish it were; it exists to expose risk, such as a core context conforming to a messy legacy ERP. Keep a shared kernel tiny; when it grows, it is a coupled monolith in disguise.
Ask for it
- upstream / downstream
- customer–supplier
- conformist
- shared kernel
- open host service / published language
- anti-corruption layer
Draw a context map for Sales, Billing, Shipping, Identity and the legacy ERP: mark each link upstream/downstream with its pattern (customer–supplier, conformist, ACL, open host service with published language, shared kernel), name the owning teams, and list contracts that need versioning.