Key Principle
Context Mapping defines the relationships and integration patterns between Bounded Contexts. The mapping types encode political relationships between teams, not just technical integration patterns:
| Relationship | Power Dynamic | When It Breaks |
|---|---|---|
| Partnership | Equal, mutual dependency | When synchronization cost exceeds value; must be time-limited |
| Shared Kernel | Requires ongoing consensus on shared model | When teams diverge in priorities |
| Customer-Supplier | Upstream holds power but accommodates downstream | When corporate culture lets Supplier ignore Customer |
| Conformist | Downstream has zero influence | Tolerable only when upstream model is good enough |
| Anticorruption Layer | Downstream actively defends its model | Costly but necessary when upstream would corrupt your language |
Three integration mechanisms: RPC/SOAP, RESTful HTTP, and Messaging. Messaging eliminates temporal coupling and is the most robust choice.
Why This Matters
Every integration point is where one Ubiquitous Language meets another. The mapping type determines which language wins, whether translation occurs, or whether pollution spreads. Without an Anticorruption Layer, foreign concepts leak into your Ubiquitous Language — once language is corrupted, the model follows, producing the Big Ball of Mud.
Good Examples
Messaging over RPC/REST: Messaging eliminates temporal coupling by design. Latency is a first-class concern from the start, forcing resilience rather than assuming availability. Two essential patterns: At-Least-Once Delivery (periodic redelivery handles loss) and Idempotent Receiver (safe re-application handles duplicates). (Chapter 4)
Domain Event consumption without Conformism: "Consumers should not use the event types (e.g., classes) of an event publisher. Rather, they should depend only on the schema of the events, that is, their Published Language." (Chapter 4). Parse events by schema (JSON, Protobuf) rather than importing publisher classes.
Counterpoints
Integration Train Wreck: Context C1 handles a request from C0 by making a synchronous blocking call to S1, creating a cascading failure chain. This is the inevitable result of RPC-based integration without circuit breakers or asynchronous patterns. (Chapter 4)
REST API design trap: "A common mistake made when using REST is to design resources that directly reflect the Aggregates in the domain model. Doing this forces every client into a Conformist relationship." (Chapter 4). Design resources around client use cases, not internal model structure.
Partnership sustainability: Partnership mapping is flagged as hard to maintain — mutual synchronization has diminishing returns. Vernon suggests timeboxing partnerships and being willing to remap to Customer-Supplier when the cost exceeds the benefit. (Chapter 4)
Key Quotes
"The most defensive Context Mapping relationship, where the downstream team creates a translation layer between its Ubiquitous Language (model) and the Ubiquitous Language (model) that is upstream to it." — Vaughn Vernon, Chapter 4 (on Anticorruption Layer)
"Consumers should not use the event types (e.g., classes) of an event publisher. Rather, they should depend only on the schema of the events, that is, their Published Language." — Vaughn Vernon, Chapter 4
Rules of Thumb
- Prefer messaging over RPC/REST to eliminate temporal coupling
- Use Anticorruption Layers when integrating with systems whose model would pollute your language
- Design REST resources around consumer use cases, not your internal Aggregates
- Consume events by schema, never by importing the publisher's types
- Timebox Partnership relationships and reassess regularly
Related References
- Bounded Contexts and Ubiquitous Language - The boundaries being mapped
- Domain Events and Event Sourcing - The mechanism for asynchronous integration
- Anti-Patterns and Failure Modes - Integration Train Wreck and Conformist traps