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. In hexagonal architectures, this is implemented as an adapter: see Ports and Adapters.

Open Host Service

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

Published Language

A common language is shared for integration across contexts, most effectively achieved via standardized Domain Events.

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.

With strategic maps in place, we transition from system-wide relationships to internal model construction in Tactical Design with Aggregates.