What needs to be finished first
A big-picture event-storming or comparable domain discovery artifact exists from which Bounded Contexts can be derived.
At least one narrated domain story exists with actors, work objects, and handoffs, from which context boundaries become visible.
What needs to be ready before start
Whiteboard or Miro area for boxes (Bounded Contexts), arrows (relationships), and relationship-legend (Shared Kernel, Customer/Supplier, Conformist, ACL, OHS, Published Language, Partnership); known subdomain list; owner list.
An Architect or Domain Modeler as facilitator; 3-10 participants from engineering and domain (owner per context); one scribe for boundary notes; one decider for conflicts.
Existing service landscape (documentation, repo list); subdomains from domain discovery; team topology and ownership data; known interface issues from last months.
1-3 h
Set up three wall zones: contexts, relationships, hot spots. Make DDD relationship legend visible. Rule: map shows business boundaries, not repository structure.
The one question this method answers
Which Bounded Contexts and which relationships between them shape today's domain landscape, and where are the biggest friction points?
Marker: Phase
| Step | Duration | Action | Hint |
|---|---|---|---|
1Phase 1: Identify contexts | 30-45 min | Post bounded contexts or subdomains as boxes on the wall. For each box: name, owner team, short purpose. Mark subdomain type (core, supporting, generic). | If 20+ contexts emerge, they are too fine-grained or subdomains are being conflated with microservices. Prefer 6-12 business contexts. |
2Phase 2: Draw relationships | 30-60 min | Draw arrows between context pairs and label with relationship type (for example Customer/Supplier with upstream/downstream, Conformist, ACL, Shared Kernel). Use question mark for unclear relationships. | Relationship type is not data flow direction; it is power relationship and translation need. Treating them as data flow creates wrong protective layers. |
3Phase 3: Mark hot spots | 20-30 min | Attach pink notes on relationship friction: frequent bugs, unclear ownership, semantic conflicts. Also mark unused relationships (potentially dead integrations). | Hot spots are valuable output. Expect 3-5 at minimum, otherwise discussion was too polite. Name concrete incidents, not abstract concerns. |
4Phase 4: Implications and actions | 20-30 min | Define owner and follow-up action for each hot spot (spike, ADR, interface review). At least three actions with dates. Photograph and version the map. | A map without actions is decorative. Set a follow-up review 4-6 weeks later to review actions and changes. |
What comes out at the end
Completed context map as SVG or diagram file with boxes for each bounded context (name, owner, type), arrows with relationship types, hot spots marked, and a relationship table with description plus next actions with owner and date.
One entry per release with date and version. Keep prior maps. Mark changes (new contexts, changed relationships, resolved hot spots) as deltas. Review at least semi-annually.
Compact working template for Domain 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
Relationships
orders.v3.Hot Spots
Follow-up review: 30.06.2026.
Recognize symptoms and steer against them
Contexts match microservices or repositories rather than business areas.
Derive contexts from domain discovery, not from code structure. Ask: is there distinct language and model here? If not, no context.
Arrows show data flow but relationship types do not match reality.
Explain DDD relationship types (power, translation responsibility). Ask: who adapts to whom? Who translates? Then set arrow and type.
Shared Kernel across many contexts, everyone changes shared model, coordination needed daily.
Treat Shared Kernel as exception only. Prefer ACL when conflicts emerge or split the kernel.
A clean and polite map with no identified frictions. Group avoids conflict.
Facilitator should ask for recent incidents, interface bugs, and escalations. Hot spots are the most valuable result.
Map is drawn, photographed, archived; in 3 months nobody remembers.
Assign an ADR, RFC, or spike for each hot spot with owner and date. Plan a fixed review date, not "when convenient."
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.