Strategic Design with Context Mapping

In the previous articles we explored how to discover bounded contexts and keep each model consistent within its boundaries.
But in real systems, bounded contexts rarely live in isolation. They need to interact — exchanging data, triggering processes, or serving as the foundation for other contexts.

This is where context mapping comes into play.
It helps us make these relationships explicit and choose the right strategy for integration.

What Is Context Mapping?

A context map is a diagram or model that shows how different bounded contexts relate to each other.
It makes visible the dependencies, power dynamics, and integration patterns that would otherwise stay hidden.

By capturing these relationships, teams can plan their collaborations better, avoid accidental coupling, and make more intentional design choices.

Common Kinds of Context Mappings

There are several patterns for context relationships. Some are cooperative, others are protective, and a few are simply warnings of what to avoid.

Partnership

Two teams work closely together, sharing a common goal and adjusting their models collaboratively.

Shared Kernel

A subset of the model is shared between teams. This requires high trust and coordination, since changes in the shared part affect everyone.

Customer–Supplier

One context depends on another to provide services. The supplier may or may not adjust to meet the customer’s needs, depending on priorities.

Conformist

The consuming context has little influence and must simply adapt to the supplier’s model, even if it is not ideal.

Anticorruption Layer

A protective layer that shields a context from a poorly designed or mismatched external model, translating into its own terms.

Open Host Service

A context exposes well-defined, open interfaces (such as APIs) for others to use.

Published Language

A common language (like an agreed event schema) is shared for integration across contexts.

Separate Ways

Sometimes the best strategy is not to integrate at all — contexts can evolve independently.

Big Ball of Mud

A warning sign: boundaries are unclear, dependencies are tangled, and no consistent model exists. This is what context mapping tries to prevent.

Making Good Use of Context Mapping

A context map is not only a conceptual tool. It directly influences technical choices.

• RESTful HTTP
  Useful when one context needs to expose well-defined resources, often fitting the Open Host Service or Customer–Supplier patterns.

• Messaging
  Asynchronous communication (using events or queues) supports looser coupling, aligning well with Published Language or Anticorruption Layer strategies.

The important point is that the integration style should reflect the relationship. If teams are in a conformist position, forcing an elaborate anticorruption layer may not be realistic. If the goal is independence, then asynchronous messaging and separate databases make more sense.

An Example in Context Mapping

Consider an online retail system:

• The Ordering context depends on the Payment context to process transactions. This is a Customer–Supplier relationship: Ordering acts as the customer, Payment as the supplier.
• The Shipping context receives events from Ordering once an order is confirmed. This uses a Published Language through a shared event schema like OrderPlaced.
• The Customer Support context deals with complex or legacy data structures from both Ordering and Shipping. To protect its own model and ensure stability, it implements an Anticorruption Layer that translates these external models into its own clean, simplified domain concepts.

When these relationships are drawn on a context map, the team gains a shared understanding of how systems interact — not just technically, but also organizationally.

Closing Thoughts

Context mapping is a cornerstone of strategic design.
It allows teams to go beyond modeling inside their own boundaries and start reasoning about how different parts of the system collaborate.

By choosing the right mapping strategy — partnership, anticorruption, conformist, or otherwise — we reduce friction, align with business priorities, and keep our architecture intentional.

In short: context mapping prevents integration from being an afterthought. It turns it into a deliberate design choice that supports both the business and the teams building the software.