methodatlas
Session Builder

Plan my session

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

Method session1-3 hWorkshop or asyncContext Canvas

Session: Bounded Context Canvas

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-8. 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 Context Canvas. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Section 1: Name and purpose

    10 min

    Use the context name as a domain term, not as a service name. Write the purpose in two sentences: which business problem this context solves and which outcome it produces. Hint: If the name sounds like a microservice ('order-service'), it is too technical. Use a domain term from the ubiquitous language.

    FacilitatorContext Canvas
  2. 2

    Section 2: Strategic classification

    10 min

    Classify along three axes: Domain (Core, Supporting, Generic), Business Model (Revenue, Engagement, Compliance, Cost Reduction), Evolution (Genesis, Custom, Product, Commodity). Hint: Core domains need the best people. If everything is classified as Core, the strategy is unclear or the team is overconfident.

    FacilitatorGlossary
  3. 3

    Section 3: Domain roles

    10 min

    Which role does the context play (Specification, Execution, Audit, Approver, Analysis, Gateway)? Multiple roles are possible, but they need justification. Hint: More than three domain roles point to a God Context. Check whether the canvas should be split.

    FacilitatorIntegration Notes
  4. 4

    Section 4: Inbound and outbound communication

    30 min

    For each interface: counterpart context, frequency, data, integration pattern (Customer-Supplier, Conformist, ACL, Open Host Service, Published Language). Separate inbound commands and queries from outbound events. Hint: If inbound and outbound use different language, translation (ACL) is mandatory. Missing ACLs with differing language create model leaks.

    FacilitatorContext Canvas
  5. 5

    Section 5: Ubiquitous language and business decisions

    20 min

    Collect 10-20 central terms with a short definition. Note three to five important business decisions (rules, policies, invariants) enforced by the context. Hint: If a term means different things to different stakeholders, define it here explicitly. Otherwise the ambiguity leaks into code and tickets.

    FacilitatorGlossary
  6. 6

    Section 6: Assumptions and risks

    10 min

    Capture open assumptions, missing clarity, and known risks. Name an owner and next action for each entry. Hint: An empty assumptions block is a warning sign. Every context has uncertain assumptions; without this reflection, the canvas is polished but shallow.

    OwnerIntegration Notes
  7. 7

    Publish artifact

    10 min

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

    OwnerContext Canvas
Usable artifact

Session Brief

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

session-brief.md

Session Brief: Bounded Context Canvas

Goal

Artifact: Context Canvas

Working Question

Which domain boundary defines this context, which language applies inside it, and how does it integrate with its neighbors?

Context

Provisional context name; list of known upstream and downstream systems with integration type; existing service documentation; relevant ADRs for interfaces.

Setup

  • Format: Method session
  • Duration: 1-3 h
  • Mode: Workshop or async
  • Participants: One context owner (team lead or tech lead); two to three domain experts from the business domain; one to three engineers; optionally a DDD coach for the team's first canvases.
  • Owner: One context owner (team lead or tech lead)
  • 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 Context Canvas. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Bounded Context Canvas template (ddd-crew GitHub) as a Miro template or A1 printout; sticky notes in four colors for Domain Roles, Strategic Classification, Inbound, and Outbound; markers; glossary area at the edge.

Preparation

Place the canvas on the work surface and label the fields (Name, Purpose, Strategic Classification, Domain Roles, Inbound Communication, Outbound Communication, Ubiquitous Language, Business Decisions, Assumptions). Put the glossary column on the right. Set the timer to 90 min.

Agenda

  1. Section 1: Name and purpose (10 min) Owner: Facilitator Action: Use the context name as a domain term, not as a service name. Write the purpose in two sentences: which business problem this context solves and which outcome it produces. Hint: If the name sounds like a microservice ('order-service'), it is too technical. Use a domain term from the ubiquitous language. Output: Context Canvas

  2. Section 2: Strategic classification (10 min) Owner: Facilitator Action: Classify along three axes: Domain (Core, Supporting, Generic), Business Model (Revenue, Engagement, Compliance, Cost Reduction), Evolution (Genesis, Custom, Product, Commodity). Hint: Core domains need the best people. If everything is classified as Core, the strategy is unclear or the team is overconfident. Output: Glossary

  3. Section 3: Domain roles (10 min) Owner: Facilitator Action: Which role does the context play (Specification, Execution, Audit, Approver, Analysis, Gateway)? Multiple roles are possible, but they need justification. Hint: More than three domain roles point to a God Context. Check whether the canvas should be split. Output: Integration Notes

  4. Section 4: Inbound and outbound communication (30 min) Owner: Facilitator Action: For each interface: counterpart context, frequency, data, integration pattern (Customer-Supplier, Conformist, ACL, Open Host Service, Published Language). Separate inbound commands and queries from outbound events. Hint: If inbound and outbound use different language, translation (ACL) is mandatory. Missing ACLs with differing language create model leaks. Output: Context Canvas

  5. Section 5: Ubiquitous language and business decisions (20 min) Owner: Facilitator Action: Collect 10-20 central terms with a short definition. Note three to five important business decisions (rules, policies, invariants) enforced by the context. Hint: If a term means different things to different stakeholders, define it here explicitly. Otherwise the ambiguity leaks into code and tickets. Output: Glossary

  6. Section 6: Assumptions and risks (10 min) Owner: Owner Action: Capture open assumptions, missing clarity, and known risks. Name an owner and next action for each entry. Hint: An empty assumptions block is a warning sign. Every context has uncertain assumptions; without this reflection, the canvas is polished but shallow. Output: Integration Notes

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

Closeout

  • Update result artifact: Context Canvas
  • 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

Context Canvas: Bounded Context Canvas

Working Question

Which domain boundary defines this context, which language applies inside it, and how does it integrate with its neighbors?

Context

Provisional context name; list of known upstream and downstream systems with integration type; existing service documentation; relevant ADRs for interfaces.

Participants

  • Owner: One context owner (team lead or tech lead)
  • Participants: One context owner (team lead or tech lead); two to three domain experts from the business domain; one to three engineers; optionally a DDD coach for the team's first canvases.

Input

Bounded Context Canvas template (ddd-crew GitHub) as a Miro template or A1 printout; sticky notes in four colors for Domain Roles, Strategic Classification, Inbound, and Outbound; markers; glossary area at the edge.

Template

Bounded Context Canvas Working Template

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

  • Context Canvas:
  • Glossary:
  • Integration Notes:

Open questions

  • ...

Next step

Owner, date, success signal.

Completion Check

  • Context Canvas 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

Bounded Context Canvas Working Template

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

bounded-context-canvas-working-template.md

Compact working template for Bounded Context Canvas with context, input, output artifacts, and next step.

Bounded Context Canvas Working Template

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

  • Context Canvas:
  • Glossary:
  • Integration Notes:

Open questions

  • ...

Next step

Owner, date, success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Context Canvas.
  • Keep every canvas in Git with version number in the filename or header. For larger changes (domain classification, new integrations), create a new version and keep the old one. Add a change log at the end with date and reason.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet