ArtifactChapter I · Domain · Building block 6 of 7

Context Map

A context map shows Bounded Contexts and their business relationships. It makes dependencies, information flows and translation points visible.

  1. Upstream and DownstreamUpstream pretends, downstream adapts.
  2. Relationship patternsThe model specifies the type of cooperation.
  3. Change effectIt shows who is responding to a change.

Context

Why this is important

A context map shows who prescribes the model and who adapts. The patterns describe how teams work together and who has influence; according to Conway’s Law, system boundaries mirror the organization’s communication. The inner meaning of a single boundary is dealt with by the building block Bounded Context.

This building block explains relationships between model boundaries. For the inner meaning of a single border, see Bounded Context.

At a glance · Contexts and their relationships

The context map shows which context dictates, which adapts, and where a translation layer provides protection.
Shop example · Relationship card

Who gives the model?

In the shop, there are relationships within the team, in which warehouse, payment and order are coordinated. Externally, there is a relationship with the payment provider, whose model does not influence the shop.

This is how you read the picture

  1. Upstream and Downstream U and D at the line ends, such as U at the payment provider and D at the payment.
  2. Relationship patterns The chip on each line: ACL, C/S (customer/supplier) or PL (published language).
  3. Change effect The field “If ... changes” indicates what is adjusted and what remains untouched.
What flows
translated order back, provider codes (APPROVED, DECLINED, PENDING_REVIEW) back
Who adapts
The payment adjusts; the ACL shields the rest of the shop.
If Payment provider Changes
If the provider renames a code, only the ACL in the payment is adjusted; the order remains unaffected.
Influence of Payment
No influence on the upstream

Classification illustrative

Choose a relationship on the map or in the list: U specifies the model, D adapts; the arrangement is illustrative.

Benefits & limitations

Helps if:

  • Several business models work together and their dependencies must be coordinated.
  • An external or upstream contract influences the terminology and changes within your own domain area.

Boundaries

  • A map quickly becomes obsolete and is only as good as its last update. It is part of every change in integration.
  • With a small team and a monolith, many relationship patterns are less pronounced. The map is particularly useful at external boundaries such as the payment provider, where an Anti-Corruption Layer protects the local model.

In practice

  1. Capture contexts and owners. Designate model boundaries and teams responsible for data or contracts. The result shows to whom open integration issues are addressed.
  2. Describe relationships and their direction. Record who supplies, who consumes and whether the integration uses a shared model or translation. Link the map to the relevant Bounded Contexts.
  3. Review change risks and protection. Mark unstable dependencies and clarify how local language remains protected. An Anti-Corruption Layer is an option when external semantics would otherwise enter the business core.
Read the detailed explanation

Contexts exchange information and influence one another through shared contracts, dependencies or translations. A Context Map shows who supplies terminology and interfaces, who consumes them and how changes are coordinated. Bounded Context defines the models involved; an Anti-Corruption Layer can protect local language from assumptions in an external model.

Relationship type and direction explain more than connection lines alone. The map should show actual collaboration, team ownership and known risks. Update it when contracts, suppliers or organisational responsibilities change. Labels expose dependencies, influence over other parties and translation work.

Established relationship patterns provide a vocabulary: a Shared Kernel is a jointly maintained part of a model; in Customer/Supplier, the supplier responds to the customer's needs; a Conformist adopts another model unchanged; an Open Host Service offers a maintained public interface for multiple consumers. The payment provider controls its own model; the shop translates it through an Anti-Corruption Layer rather than acting as a Conformist. Other patterns include Partnership, where teams plan together, and Separate Ways, where contexts are deliberately left unintegrated.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    What relationship does the payment provider have with the payment, and who adapts?

    View the solution with justification

    The payment provider is upstream, the payment is downstream. The payment adapts, protected by an anti-corruption layer; the shop has no influence on the provider.

  2. ApplyingTransferred to a new situation

    The payment provider renames PENDING_REVIEW. What contexts do you need to change?

    View the solution with justification

    Only the payment: The ACL translates the new code further into “Clarification is running”. Order and invoice do not know the provider code and remain unchanged.

  3. EvaluateWeighing an alternative

    The team wants to take over the codes of the provider directly (Conformist) in order to save the ACL. How do you rate that?

    View the solution with justification

    Advantage: less code and translation. Disadvantage: The provider codes migrate into order and invoice, and every change of the provider hits the whole shop. Recommendation: keep ACL because the provider is external and determines its model itself.

Continue on the learning path

Next in Domain modelling: Anti-Corruption Layer.