Domain Modeling Mapping tool

Context Map

A context map shows bounded contexts and their integration relationships, dependencies, and translation boundaries.

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.

Core question

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

Prepare plan Method guide

Start comparison

Give feedbackIs this method useful to you?

Participants: 2-8
Time: 1-3 h

Phases may be revisited; their order supports the work but does not replace domain judgment.

Context Map workspace showing the question, observations, and next decision.

Contexts
Name contexts and models
Locate model boundaries by language and rules; note terms that mean something different elsewhere.
Relationships
Map relationships
Draw data or process flow with direction and name upstream/downstream.
Integration
Clarify integration patterns
Choose patterns such as customer-supplier, conformist, or ACL based on actual collaboration.
Clarification
Mark friction and next decision
Mark shared kernels, translation, bottlenecks, and unresolved conflicts; assign investigation.

Review the result and open assumptions at the next suitable checkpoint. Record changes, ownership, and new evidence.

A good fit when

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

Ideal for

DDD Strategy
Microservice Boundaries
Integration Planning

Not good for

Story-level discovery
UI design

Outputs

Working picture
Working picture with model boundaries based on language and rules, including terms with different meanings elsewhere.
Testable evidence
The artifact records patterns such as customer-supplier, conformist, or ACL based on actual collaboration.
Next step
The overview marks shared kernels, translation, bottlenecks, and unresolved conflicts and assigns the investigation.

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

First step

Start with a bounded question, clarify access and participants, and collect available evidence. Show bounded contexts and their integration relationships, dependencies, and translation boundaries.

Open the method guide

Good to do first

Domain Modeling

EventStorming

Supplies several domain boundaries that get related to each other here.

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.

Architecture

C4 Model

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

Deep dive

Purpose

When several contexts need to talk to each other, it makes their relationships and dependencies legible. It helps sort integration pressure and responsibilities across system boundaries.

How it works

It places contexts with their connections into one shared picture and shows where handoffs, translations, or couplings arise. This makes architecture conversations about boundaries, flows, and responsibility more concrete.

In detail

A Context Map helps because it doesn't just name contexts but makes the quality of their relationships visible. Good use deliberately separates business dependency, organizational reality, and technical coupling so the picture doesn't turn into wishful architecture. Its value unfolds where power relations, translation effort, and need for protection become explicit, making integration decisions more solid.

Facilitation

Before the session, gather real exchange points between contexts, such as data handoffs, approvals, or conflicts over terms. The tipping point usually comes at the question of who has to align with whom. Close the work with a few marked problem relationships and a prioritized clarification for the riskiest coupling.

The method guide walks execution through 4 phases, timing, 4 pitfalls, and clear stop criteria.

Open method guide

Your perspective

Does this method help with your work?

Your feedback helps shape the next improvements to methodatlas.

Sources and topics

Topics

Domain-Driven Design Boundaries Strategy

Sources

Bounded Context · Martin Fowlermartinfowler.comMethod reference reviewed to support the scope and workflow of Context Map. Examples and editorial guidance are original and explicitly fictional.

In playbooks

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

Artifact templates

Context Map: WorksheetPrepare Context Map with a clear question, roles, and sources.

markdown

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.