methodatlas
Session Builder

Plan my session

Plan a concrete work block with agenda, roles, preparation, and a copyable result artifact.

Method session1-3 hWorkshopDomain Context Map

Session: Domain Context Map

The plan translates the method into a concrete facilitated work block. Your inputs flow directly into the session brief and work artifact.

Derived automatically

Method session with 3-10. The plan uses the existing method logic and the runsheet.

Runsheet
Participation logic
Team round, shared work and alignment

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome logic
Finish artifact

The session works directly toward Domain Context Map. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Phase 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). Hint: If 20+ contexts emerge, they are too fine-grained or subdomains are being conflated with microservices. Prefer 6-12 business contexts.

    FacilitatorDomain Context Map
  2. 2

    Phase 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. Hint: Relationship type is not data flow direction; it is power relationship and translation need. Treating them as data flow creates wrong protective layers.

    FacilitatorBoundary Notes
  3. 3

    Phase 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). Hint: Hot spots are valuable output. Expect 3-5 at minimum, otherwise discussion was too polite. Name concrete incidents, not abstract concerns.

    FacilitatorOwnership Map
  4. 4

    Phase 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. Hint: A map without actions is decorative. Set a follow-up review 4-6 weeks later to review actions and changes.

    OwnerDomain Context Map
  5. 5

    Publish artifact

    10 min

    Check the artifact for completeness, define location, set version or status, and name review recipients.

    OwnerDomain Context Map
Usable artifact

Session Brief

For invitations, boards, tickets, PR descriptions, or workshop notes.

session-brief.md

Session Brief: Domain Context Map

Goal

Artifact: Domain Context Map

Working Question

Which Bounded Contexts and which relationships between them shape today's domain landscape, and where are the biggest friction points?

Context

Existing service landscape (documentation, repo list); subdomains from domain discovery; team topology and ownership data; known interface issues from last months.

Setup

  • Format: Method session
  • Duration: 1-3 h
  • Mode: Workshop
  • Participants: 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.
  • Owner: An Architect or Domain Modeler as facilitator
  • Participation mode: Team round, shared work and alignment
  • Outcome logic: Finish artifact

Participation Logic

Use the session for shared understanding. Contributions are collected visibly, assumptions are aligned, and open differences remain traceable in the artifact.

Outcome Logic

The session works directly toward Domain Context Map. After the session, the artifact should be shareable, reviewable, or reusable.

Input

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.

Preparation

Set up three wall zones: contexts, relationships, hot spots. Make DDD relationship legend visible. Rule: map shows business boundaries, not repository structure.

Agenda

  1. Phase 1: Identify contexts (30-45 min) Owner: Facilitator Action: Post bounded contexts or subdomains as boxes on the wall. For each box: name, owner team, short purpose. Mark subdomain type (core, supporting, generic). Hint: If 20+ contexts emerge, they are too fine-grained or subdomains are being conflated with microservices. Prefer 6-12 business contexts. Output: Domain Context Map

  2. Phase 2: Draw relationships (30-60 min) Owner: Facilitator Action: 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. Hint: Relationship type is not data flow direction; it is power relationship and translation need. Treating them as data flow creates wrong protective layers. Output: Boundary Notes

  3. Phase 3: Mark hot spots (20-30 min) Owner: Facilitator Action: Attach pink notes on relationship friction: frequent bugs, unclear ownership, semantic conflicts. Also mark unused relationships (potentially dead integrations). Hint: Hot spots are valuable output. Expect 3-5 at minimum, otherwise discussion was too polite. Name concrete incidents, not abstract concerns. Output: Ownership Map

  4. Phase 4: Implications and actions (20-30 min) Owner: Owner Action: 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. Hint: A map without actions is decorative. Set a follow-up review 4-6 weeks later to review actions and changes. Output: Domain Context Map

  5. Publish artifact (10 min) Owner: Owner Action: Check the artifact for completeness, define location, set version or status, and name review recipients. Output: Domain Context Map

Closeout

  • Update result artifact: Domain Context Map
  • Define location, version, and review recipients.
  • Define owner, next step, and review date.
Usable artifact

Work artifact

Pre-filled starting point based on the matching template.

work-artifact.md

Domain Context Map: Domain Context Map

Working Question

Which Bounded Contexts and which relationships between them shape today's domain landscape, and where are the biggest friction points?

Context

Existing service landscape (documentation, repo list); subdomains from domain discovery; team topology and ownership data; known interface issues from last months.

Participants

  • Owner: An Architect or Domain Modeler as facilitator
  • Participants: 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.

Input

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.

Template

Domain Context Map Canvas

Context

What is this method used for?

Core question

Which question should be answered at the end?

Input

Which data, observations, or materials are available?

Working area

  • Area 1:
  • Area 2:
  • Area 3:
  • Relationships / patterns:

Output artifacts

  • Domain Context Map:
  • Boundary Notes:
  • Ownership Map:

Open questions

  • ...

Next step

Owner, date, success signal.

Completion Check

  • Domain Context Map is complete enough for review:
  • Location:
  • Version / status:
  • Review by:
  • Next step:

Next Step

  • Review result
  • Mark open questions
  • Schedule review or decision
Template base

Domain Context Map Working Template

View templateCompact working template for Domain Context Map with context, input, output artifacts, and next step.
canvas

domain-context-map-working-template.md

Compact working template for Domain Context Map with context, input, output artifacts, and next step.

Domain Context Map Canvas

Context

What is this method used for?

Core question

Which question should be answered at the end?

Input

Which data, observations, or materials are available?

Working area

  • Area 1:
  • Area 2:
  • Area 3:
  • Relationships / patterns:

Output artifacts

  • Domain Context Map:
  • Boundary Notes:
  • Ownership Map:

Open questions

  • ...

Next step

Owner, date, success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Domain Context Map.
  • 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.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet