Skip to content
Software Architecture Guide

Context Map

Explanation

Section titled “Explanation”

A context map is a picture of the bounded contexts in a system and how they relate. A bounded context is a part of the system with its own model and vocabulary (see the article Bounded Context). Strategic DDD is the big-picture side of Domain-Driven Design.

Why draw one. Different contexts often model the same concepts differently. Fowler says a context map is usually worthwhile for showing these differences.

Upstream and downstream. The map draws relationships as influence and data flows. The upstream context provides information or services. The downstream context consumes them. In Context Mapper’s notation, arrows point from upstream to downstream. Two relationships are symmetric, so neither side is upstream: partnership and shared kernel.

Named relationship patterns. Teams describe each link with a named pattern. Examples are Shared Kernel, Open Host Service and Published Language. Some details matter:

  • Shared Kernel is the default symmetric relationship in Context Mapper.
  • A generic upstream-downstream link is not automatically customer-supplier. Customer-supplier is a special form of it.
  • Conformist does not apply inside a customer-supplier relationship. Customer-supplier means the downstream side can influence the upstream side.

Notation. DDD does not mandate any notation. Authors draw maps in their own styles, so explain what your arrows mean. Context Mapper offers a modeling language where the context map is the central element. It contains the bounded contexts and defines their relationships.

Example

Section titled “Example”

An online shop has three contexts: Ordering, Payment and Shipping. Ordering is upstream of Shipping, so an arrow points from Ordering to Shipping. The team labels the link with the pattern name it uses and adds a legend that says what the arrows mean.

Trade-offs

Section titled “Trade-offs”

Because DDD prescribes no notation, every map looks different. Readers may misread arrows unless the map explains them. Choosing a pattern also takes care: for example, labeling a link customer-supplier claims the downstream side has influence on the upstream side. Evans also warns that a bounded context shared by two teams risks becoming a big ball of mud (see Big Ball of Mud).

A small context map: arrows point from upstream to downstream; the shared kernel link is symmetric.

Diagram source 
flowchart LR
  O[Ordering context] -->|upstream to downstream| S[Shipping context]
  O -->|upstream to downstream| P[Payment context]
  P <-->|shared kernel| S

Checks

Section titled “Checks”
  • The document includes a context map that shows the relationships between bounded contexts.
  • Arrows in the map are explained, including which side is upstream and which is downstream.
  • Each relationship is labeled with a named pattern such as Shared Kernel, Open Host Service or Published Language.
  • Customer-supplier is used only where the downstream side has influence on the upstream side.
Section titled “Related”

Sources

Section titled “Sources”