What needs to be finished first
At least one big-picture Event Storming has been done so that Bounded Contexts exist as boundary candidates.
For at least three Bounded Contexts, a canvas with responsibilities and ubiquitous language is available.
What needs to be ready before start
Whiteboard or Miro board with space for 5-15 Contexts; symbol set for DDD relationship patterns (Partnership, Shared Kernel, Customer-Supplier, Conformist, Anti-Corruption Layer, Open Host Service, Published Language, Big Ball of Mud); relationship lines with direction; note stickies for pain points.
One facilitator with DDD experience; architect(s) with system overview; one Tech Lead per Context; Product Owner per Context; one scribe.
List of known Bounded Contexts with short descriptions; existing integrations (API, events, databases); known pain points (rework, inconsistencies, long release cycles); team organization per Context.
3-4 h for medium domains, 1 day for complex domains
Place Contexts as circles on the wall. Show a legend with the patterns. Announce the rule: relationships are asymmetrical, arrows point from downstream to upstream (dependency).
The one question this method answers
Which Bounded Contexts exist, how are they integrated, where does friction and model drift occur, and which relationship patterns are appropriate?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Inventory Contexts | 30 min | Place all known Bounded Contexts as circles on the wall. Assign an owner team and short responsibility per Context. Mark duplication or overlap explicitly. | If 25 Contexts appear, granularity is too fine. Focus on strategic level, do not include technical modules as separate Contexts. |
2Phase 2: Identify Relationships | 60 min | Ask for each Context pair: is there a relationship (data, events, API). If yes, draw an arrow (upstream to downstream). Record strength and type of the relationship. | If every Context is connected to every other context, modularization has failed or the map is too coarse. Make both visible and avoid overpainting. |
3Phase 3: Assign Patterns | 60 min | Choose the matching pattern for each relationship: Partnership (equal standing), Shared Kernel (shared code), Customer-Supplier (downstream negotiates), Conformist (downstream accepts), ACL (downstream protects itself), Open Host Service, Published Language, Big Ball of Mud (anti-pattern). | Patterns are not wishes, they are diagnostics. If the current reality is a Big Ball of Mud, mark it honestly. Document target patterns separately. |
4Phase 4: Pain Points and Target State | 45 min | Mark pain points on relationships (long releases, bug risk, duplicate models). For each top 3 pain point, define a target relationship type and measures. | Target state is not 100% clean, it is a pragmatic improvement within 6-12 months. Introducing ACL is often the first step. |
5Phase 5: Strategy and follow-ups | 30 min | Derive strategic consequences: which teams take over which relationship, which refactorings are needed, and which platform capabilities are missing. Add the top three measures with owner and deadline. | A Context Map without follow-up actions is map tourism. Define at least three measures with success indicators and a 3-month deadline. |
What comes out at the end
Context Map as a diagram with Contexts, relationships, and patterns, plus a table of pain points, target patterns, and actions. Includes team ownership and references to ADRs.
Create one version per iteration with a date. Archive the previous version. Document changes to relationship types with rationale. Linking to ADRs is required.
Compact working template for Context Map with context, input, output artifacts, and next step.
What is this method used for?
Which question should be answered at the end?
Which data, observations, or materials are available?
Owner, date, success signal.
Concrete filled scenario, fictional example
Concrete filled scenario, fictional example
Contexts (excerpt)
Relationships
Pain Points
Top Measures
Recognize symptoms and steer against them
The map shows 20 microservices as Contexts and loses domain anchoring.
Apply Strategic Design, not service topology. Align Contexts to business capabilities. Multiple services can belong to one Context.
Arrows show connections, but no one names the pattern.
The pattern is mandatory for each arrow. If it is not assignable, the relationship is unclear. Mark Big Ball of Mud; do not hide it.
The map shows the target state, while reality differs and pain points are missing.
Use two maps: current and target. Keep pain points in current. Treat follow-up actions as a bridge. Otherwise the discussion loses grounding.
Contexts have no owner team and no one can negotiate the relationships.
An owner team per Context is mandatory. If no team is responsible, the team topology has a gap. The Context Map exposes this gap.
Every relationship gets ACL, even where no actual need exists.
Use ACL only where model protection is actually needed. If both sides align, an Open Host Service or Partnership is often simpler.
Done signals checkable in under a minute
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.