Context maps matter because contexts never live alone. They depend on each other, and that dependency shape changes the health of the model.

Once a system has bounded contexts, the next question is how they relate. Context mapping patterns describe those relationships: who leads, who follows, where translation happens, and how much protection one model needs from another.

OOAD landing page Learning roadmap Previous: Bounded Contexts Next: Subdomains: Core, Supporting, and Generic

Why This Topic Matters

Why it matters in real Java systems

Ordering may depend on payments. Fulfillment may depend on ordering. Support may need read access across many contexts. Without explicit relationship patterns, those dependencies become ad hoc and usually leak language across boundaries.

Core Explanation

The main design idea

Context mapping patterns do for inter-context relationships what bounded contexts do for individual models: they make the design visible. Patterns such as Customer-Supplier, Conformist, Shared Kernel, and Anti-Corruption Layer describe how one context should integrate with another and how much of the upstream language it can safely absorb.

This matters because integration shape is part of the domain design, not just an implementation detail.

Concept Breakdown

Key ideas to keep in mind

Concept

Customer-Supplier

One context depends on another and negotiates the interface more collaboratively.

Concept

Conformist

A downstream context accepts the upstream model with limited power to change it.

Concept

Anti-Corruption Layer

A downstream context protects itself with translation rather than adopting the upstream language directly.

Practical mapping guide

Relationship	When it appears	Main concern
Customer-Supplier	Dependent teams can collaborate	Keep the interface sustainable for both sides
Conformist	One side has little influence	Avoid pretending the downstream has model independence
Anti-Corruption Layer	Upstream language would damage the downstream model	Translate and protect meaning explicitly

Java Example

Java example in the Order Management domain

Java example: explicit anti-corruption translation

package org.javaomnibus.ecommerce.payments.integration;

public final class OrderingPaymentTranslator {
    public PaymentAuthorizationRequest translate(OrderPaymentRequest request) {
        return new PaymentAuthorizationRequest(
            request.orderId().value(),
            request.amount().amount(),
            request.amount().currency()
        );
    }
}

Code Walkthrough

Step by step

The translator exists so the payment context does not have to directly adopt ordering-language objects.
This protects the downstream model from foreign assumptions.
That protection is often worth extra code when the models should remain distinct.
This is what context maps make explicit.

Real-World Usage

Where this helps in practice

Designing API boundaries between business capabilities
Protecting new contexts from legacy model pollution
Choosing where translation should happen in large Java systems

Trade-Offs

Trade-offs and when to be careful

Translation layers add code and maintenance, but often preserve model health over time.
Shared models feel cheaper at first and often become more expensive later.

Common Mistakes

Frequent mistakes to watch for

Skipping relationship design and letting contexts integrate informally
Using shared data structures as a substitute for explicit mapping
Pretending all integrations are peer-to-peer equals
Avoiding anti-corruption layers to save time while importing long-term confusion

Related concepts

Bounded contexts Web Service Broker Anti-Corruption Layer will appear in microservices later