methodatlas
Method guideDomain Modeling

Context Map

A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.

ComplexityMedium
Time1-3 h
Participants2-8
FormatWorkshop + async
MaturityCanonical
Prepare plan
01

Prerequisite

What needs to be finished first

Complete firstClear scope

Multiple named bounded contexts with known models and at least one relevant integration flow.

Without a boundary, data, perspectives, or flows become mixed.
Complete firstAccess to evidence

Relevant people and sources can be included.

Gaps remain visible; missing evidence must not be invented.
02

Preparation

What needs to be ready before start

Materials

Shared workspace, accessible sources, and a decision log.

People / roles

Domain experts · tech leads · facilitator

Pre-read

Clarify the question, timeframe, data access, roles, and known uncertainties in advance.

Time needed

2–4 hours for a medium domain; complex landscapes need focused follow-up sessions.

Setup

Create a shared version. Label facts, assumptions, and decisions separately.

03

Core question

The one question this method answers

Which models apply where, and how do contexts influence one another when collaborating?

04

Flow

Phases with goal, actions, output and pitfall

A context map shows bounded contexts and their integration relationships, dependencies, and translation boundaries. It makes visible where models interact and where clarification is needed.

Contexts, direction, and integration patterns

Fictional worked example

Show bounded contexts and their integration relationships, dependencies, and translation boundaries.

Context A

Name context boundary, model owner, and local terms.

Upstream: product terms and status codes.

Relationship

Show relationship, direction, interface, and exchanged information.

Downstream; ACL translates external status codes into local booking rules.

Pattern

Record pattern, teams, and actual collaboration.

Publishes BillingCompleted event; booking consumes it.

Open question

Record ambiguities, translation gaps, and next clarification.

Fictional finding: “reserved” means different things in two contexts; align glossary.

Fictional platform: “Catalog” provides product data; “Booking” consumes it in an upstream/downstream relationship. An anti-corruption layer translates external status codes into booking terms. “Billing” publishes events consumed by booking. Arrows record direction; they do not assert team ownership.

Bounded Context · Martin Fowler

  1. 1

    Contexts

    Name contexts and models

    Goal

    Is each context internally coherent?

    Inputs for this step

    • Context names, domain language, and model ownership

    Actions

    • Locate model boundaries by language and rules; note terms that mean something different elsewhere.
    • Is each context internally coherent?

    Output

    Bounded contexts and their language

    Bounded contexts and their language

    Quality check

    Is each context internally coherent?

    Pitfall

    Boundaries follow system names alone Use language, rules, and model ownership as boundary evidence.

    Timing: Part of the agreed work block; research may be separate.

  2. 2

    Relationships

    Map relationships

    Goal

    Is dependency direction clear?

    Inputs for this step

    • Integration flows, APIs, events, and data dependency

    Actions

    • Draw data or process flow with direction and name upstream/downstream.
    • Is dependency direction clear?

    Output

    Directed dependency and integration map

    Directed dependency and integration map

    Quality check

    Is dependency direction clear?

    Pitfall

    Arrow direction is ambiguous Define an upstream/downstream legend and verify each relationship.

    Timing: Part of the agreed work block; research may be separate.

  3. 3

    Integration

    Clarify integration patterns

    Goal

    Do both sides understand the pattern?

    Inputs for this step

    • Team relationship and relevant DDD patterns

    Actions

    • Choose patterns such as customer-supplier, conformist, or ACL based on actual collaboration.
    • Do both sides understand the pattern?

    Output

    Agreed relationship patterns between contexts

    Agreed relationship patterns between contexts

    Quality check

    Do both sides understand the pattern?

    Pitfall

    Pattern assigned without team reality Agree the pattern with both teams and actual delivery relationship.

    Timing: Part of the agreed work block; research may be separate.

  4. 4

    Clarification

    Mark friction and next decision

    Goal

    Has the map been validated as a hypothesis?

    Inputs for this step

    • Friction, translation, and unresolved boundary

    Actions

    • Mark shared kernels, translation, bottlenecks, and unresolved conflicts; assign investigation.
    • Has the map been validated as a hypothesis?

    Output

    Open model and integration risks

    Open model and integration risks

    Quality check

    Has the map been validated as a hypothesis?

    Pitfall

    Map frozen as target architecture Separate current relationship from desired change; update with evidence.

    Timing: Part of the agreed work block; research may be separate.

05

Artifact

What comes out at the end

Sketch: what the artifact looks like

Context Map · DDD RelationshipsMake Bounded Contexts and their integration relationships visible as a strategic DDD map
Context MapThe visual shows bounded contexts and DDD relationship types such as Customer/Supplier, ACL, and Shared Kernel.Make context boundaries and relationship types visibleThe Context Map shows which models stay autonomous and where integration must be designed deliberately.Customer / SupplierACL protects modelShared KernelOpen Host ServiceSales ContextCustomer / SupplierBilling ContextConformistLegacy ERPAnti-Corruption LayerIdentity ContextShared KernelRelationship typedecides coupling, not justtechnology
Form

Versioned result with question, evidence, open issues, next action, ownership, and review date.

Versioning / ownership

Record date, scope, sources, and changes. Preserve earlier observations.

Tool alternatives
  • Whiteboard or paper
  • Shared spreadsheet
  • Versioned project space

context-map-working-template.md

Prepare Context Map with a clear question, roles, and sources.

Context Map: Worksheet

Question

To be confirmed

Desired outcome

To be confirmed

Scope

Plan the full method Time: Set according to scope and available evidence

Complete this worksheet on paper or in your own document during the work.

Preparation for this scope

Method setup

  • Materials: Shared workspace, accessible sources, and a decision log.
  • Roles: Domain experts · tech leads · facilitator
  • Advance information: Clarify the question, timeframe, data access, roles, and known uncertainties in advance.
  • Overall time needed: 2–4 hours for a medium domain; complex landscapes need focused follow-up sessions.
  • Setup: Create a shared version. Label facts, assumptions, and decisions separately.

Prepare for the work steps

Contexts: Name contexts and models

  • Context names, domain language, and model ownership

Relationships: Map relationships

  • Integration flows, APIs, events, and data dependency

Integration: Clarify integration patterns

  • Team relationship and relevant DDD patterns

Clarification: Mark friction and next decision

  • Friction, translation, and unresolved boundary

Contexts, direction, and integration patterns

Context A

Name context boundary, model owner, and local terms.

...

Relationship

Show relationship, direction, interface, and exchanged information.

...

Pattern

Record pattern, teams, and actual collaboration.

...

Open question

Record ambiguities, translation gaps, and next clarification.

...

Blank worksheet: start with a bounded question. Enter observed facts only, mark assumptions, and record open questions and sources.

Bounded Context · Martin Fowler

Contexts: Name contexts and models

Expected artifact: Bounded contexts and their language

Bounded contexts and their language

Entry:

...

  • Is each context internally coherent?

Relationships: Map relationships

Expected artifact: Directed dependency and integration map

Directed dependency and integration map

Entry:

...

  • Is dependency direction clear?

Integration: Clarify integration patterns

Expected artifact: Agreed relationship patterns between contexts

Agreed relationship patterns between contexts

Entry:

...

  • Do both sides understand the pattern?

Clarification: Mark friction and next decision

Expected artifact: Open model and integration risks

Open model and integration risks

Entry:

...

  • Has the map been validated as a hypothesis?

Open questions and next steps

...

Method guide: https://methodatlas.meierhoff-systems.de/en/methods/context-map/run-sheet

06

Example output

Concrete filled scenario, fictional example

Fictional example for orientation. Counts and timings describe this case and are not universal requirements.

context-map-beispiel.md

Concrete filled scenario, fictional example

Fictional worked example

Fictional platform: “Catalog” provides product data; “Booking” consumes it in an upstream/downstream relationship. An anti-corruption layer translates external status codes into booking terms. “Billing” publishes events consumed by booking. Arrows record direction; they do not assert team ownership.

All names and values are invented for illustration. Unresolved explanations remain questions.

07

Pitfalls

Recognize symptoms and steer against them

Quick overview, the full text is in the matching phase in the flow

  1. Name contexts and modelsBoundaries follow system names aloneView in phase
  2. Map relationshipsArrow direction is ambiguousView in phase
  3. Clarify integration patternsPattern assigned without team realityView in phase
  4. Mark friction and next decisionMap frozen as target architectureView in phase
08

Stop criteria

When to pause, resolve prerequisites, or choose another approach

The question or boundary remains ambiguous: narrow it first.
Key data or participants are missing: label the gap and arrange access.
The group mixes observation and explanation: revisit the evidence.
An immediate safety or operational risk appears: stop and use the responsible procedures.

Method after Praxisgemeinschaft. The method emerged as a widespread practice and is not clearly attributed to a single originator or organization. Curated with 1 sources.

Sources: Bounded Context · Martin Fowler

Flow, timeboxes, and pitfalls are editorially curated practice recommendations based on the listed sources.

Where to go next?

Paper illustration of two considered options leading to a decision record with a marked status and visible consequences.
Architecture
Architecture Decision Record

Records the chosen integration relationship as a reasoned decision.

A paper-based illustration representing C4 Model with its core stages and visible working result.
Architecture
C4 Model

Shows the clarified context boundaries as systems and containers in detail.

View in playbookLead Domain Discovery to BoundariesMove from domain flow to language, events, bounded contexts, and first architecture boundaries.

Finished the method guide?

Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.

Go to profileMore methods