Context Mapping Patterns in Domain-Driven Design

Context mapping is a tool that allows you to identify relationships between bounded contexts and the teams responsible for them.

Vaughn Vernon’s *Implementing Domain‑Driven Design* describes several ways to integrate multiple bounded contexts:

Partnership

Shared Kernel

Customer/Supplier

Conformist

Anti‑Corruption Layer (ACL)

Open Host Service (OHS)

Published Language (PL)

Depending on the codebase, team characteristics, business domain, and involvement of third‑party software, you should flexibly apply each method. Below are brief examples of how each technique works.

Partnership

This describes the relationship between teams rather than the code itself. It works well when two teams operate in separate bounded contexts but share common goals and a ubiquitous language. Early‑stage projects benefit from fast communication, while later stages may incur higher coordination costs.

Shared Kernel

Two or more bounded contexts share a common model, often implemented as a shared library or service. While initially small, the shared kernel can become hard to maintain as each context evolves independently.

Customer/Supplier

One context (the supplier) provides functionality that another context (the customer) consumes. The supplier ultimately decides what the customer receives. This pattern fits autonomous environments within the same organization or when the customer has a single supplier.

Conformist

Here the upstream context does not support the downstream one, forcing the downstream to conform to the upstream’s API or model. This often occurs when integrating new features into a large, established solution.

Anti‑Corruption Layer (ACL)

The downstream context implements a layer that translates upstream objects into its own model, preserving its integrity and shielding it from external concepts. ACLs are useful when integrating new functionality into legacy systems treated as black‑box contexts.

Open Host Service (OHS) / Published Language (PL)

Both define a relationship where the upstream provides well‑documented integration contracts (e.g., APIs, specifications) and version support. The upstream may serve many downstream clients without tailoring to any specific one, such as integrating with an Amazon API.

In summary, understanding these context‑mapping techniques enables more effective integration of bounded contexts. Consider the business value of integration first, and feel free to combine multiple patterns when appropriate—for example, using OHS for a RESTful API while also implementing an ACL for third‑party upstream services.