Complete firstClear scope
Agree the subject, boundary and decision before filling the model.
A broad or mixed scope produces a misleading model.
Method guideDomain Modeling
Bounded Context Canvas
A practical method guide: clarify prerequisites and materials, understand the complete process, and look up outputs, pitfalls, and stop criteria.
ComplexityMedium
Time1-3 h
Participants3-8
FormatWorkshop + async
MaturityEmerging
01
Prerequisite
What needs to be finished first
Complete firstAccess to relevant evidence
Bring source material and people who know the work; distinguish facts from assumptions.
Unverified interpretations become false certainty.
02
Preparation
What needs to be ready before start
Materials
Shared visual workspace, source evidence, and an agreed decision question.
People / roles
Domain expert, product owner, architect, representatives of neighboring contexts.
Pre-read
Collect existing data, examples, constraints and relevant stakeholder perspectives.
Time needed
90–150 min per candidate context; validate boundaries with adjacent teams.
Setup
Name the business capability and bounded scope in domain language. State what this model owns and what decisions it is responsible for. List ubiquitous language, key concepts, rules and synonyms inside the boundary. Identify upstream inputs, downstream outputs, consumers and integration contracts. Check ownership, model integrity and neighboring context relationships; list open boundary questions.
03
Core question
The one question this method answers
Where should this domain boundary sit, and how will contexts collaborate?
04
Flow
Phases with goal, actions, output and pitfall
Clarifies a domain boundary, language, responsibility and integration points before teams commit to a model.
Bounded Context Canvas
Fictional example
Fictional, “Scheduling” context: responsibility: offer and confirm bookable times. Language: slot = period released by the practice; appointment = confirmed booking. Input: patient and practice IDs, requested period. Output: confirmed booking or rejection. Neighbours: practice management provides availability; notifications receive confirmed appointments. Open boundary: which system owns cancellation status?
Name
Name the domain context.
Fictional: Scheduling
Purpose
What business purpose does this context serve?
Fictional: Offer and confirm bookable times.
Strategic Classification
Core, Supporting or Generic; justify value and evolution.
Fictional: Supporting; Product evolution is a hypothesis.
Domain Roles
Which domain role does the context perform?
Fictional: Execution context for reservations.
Inbound Communication
Which messages and collaborators send information in?
Fictional: Practice system sends available slots.
Outbound Communication
Which commands, events or queries go out?
Fictional: AppointmentConfirmed to notifications.
Ubiquitous Language
Which local terms and definitions apply?
Fictional: Slot = time period released by practice.
Business Decisions
Which domain rules or policies apply?
Fictional: A conflicting booking is rejected.
Assumptions
Which model assumptions are unverified?
Fictional: Synchronization refreshes slots before booking.
Verification Metrics
Which signals test whether the context boundary fits?
Fictional: Observe conflict rate and manual intervention.
Open Questions
What remains open and who will investigate?
Fictional: Which context owns cancellation status?
- 1
Name
Name context and responsibility
Goal
Context name and purpose
Inputs for this step
- Domain capability, team mandate and decisions
Actions
- Give the bounded context a domain name and state the responsibility fulfilled by its model.
Output
Context name and purpose
Context name and purpose
Quality check
Is the boundary justified by domain responsibility?
Pitfall
The boundary follows existing code or team structure alone. Inspect language, rules and reasons for change before allocation.
Timing: Allow time according to scope and evidence; no universal duration.
- 2
Language
Capture language and model
Goal
Ubiquitous language and core model
Inputs for this step
- Domain experts, examples and disputed terms
Actions
- Define key terms locally with an example and rule; make synonyms or ambiguity explicit.
Output
Ubiquitous language and core model
Ubiquitous language and core model
Quality check
Do domain experts understand every term alike?
Pitfall
A term is assumed to mean the same model across contexts. Document context-specific definitions and translations.
Timing: Allow time according to scope and evidence; no universal duration.
- 3
Interface
Clarify inputs and outputs
Goal
Interface overview
Inputs for this step
- Neighbouring systems, events, APIs and data ownership
Actions
- List domain inputs and outputs with producer, consumer, contract and change cadence.
Output
Interface overview
Interface overview
Quality check
Is a source of truth named for every datum?
Pitfall
Data flows lack an owner or contract. Add source, recipient and failure responsibility.
Timing: Allow time according to scope and evidence; no universal duration.
- 4
Boundary
Review relationships and boundaries
Goal
Context canvas with resolved and open points
Inputs for this step
- Context model, team responsibilities and integration cases
Actions
- Check neighbouring contexts, upstream/downstream influence and translation needs; assign owners to open boundary questions.
Output
Context canvas with resolved and open points
Context canvas with resolved and open points
Quality check
Are dependencies and translations explicit?
Pitfall
The canvas is treated as a binding team topology. Separate model boundary from team decision and validate each.
Timing: Allow time according to scope and evidence; no universal duration.
05
Artifact
What comes out at the end
Sketch: what the artifact looks like
Form
Clarifies a domain boundary, language, responsibility and integration points before teams commit to a model. Record scope, evidence, assumptions, owner and next review in the versioned artifact.
Versioning / ownership
Record scope, date, participants, source version and owner. Note changed assumptions and the reason for each revision.
Tool alternatives
- Shared whiteboard or paper template
- Source links, records or measurement data
bounded-context-canvas-working-template.md
Prepare the decision, source evidence and next review.
Bounded Context Canvas: Worksheet
Question
To be confirmed
Desired outcome
To be confirmed
Scope
Run the method Time: See catalog planning range; no universal duration.
Complete this worksheet on paper or in your own document during the work.
Preparation for this scope
Method setup
- Materials: Shared visual workspace, source evidence, and an agreed decision question.
- Roles: Domain expert, product owner, architect, representatives of neighboring contexts.
- Advance information: Collect existing data, examples, constraints and relevant stakeholder perspectives.
- Overall time needed: 90–150 min per candidate context; validate boundaries with adjacent teams.
- Setup: Name the business capability and bounded scope in domain language. State what this model owns and what decisions it is responsible for. List ubiquitous language, key concepts, rules and synonyms inside the boundary. Identify upstream inputs, downstream outputs, consumers and integration contracts. Check ownership, model integrity and neighboring context relationships; list open boundary questions.
Prepare for the work steps
Name: Name context and responsibility
- Domain capability, team mandate and decisions
Language: Capture language and model
- Domain experts, examples and disputed terms
Interface: Clarify inputs and outputs
- Neighbouring systems, events, APIs and data ownership
Boundary: Review relationships and boundaries
- Context model, team responsibilities and integration cases
Bounded Context Canvas
Name
Name the domain context.
...
Purpose
What business purpose does this context serve?
...
Strategic Classification
Core, Supporting or Generic; justify value and evolution.
...
Domain Roles
Which domain role does the context perform?
...
Inbound Communication
Which messages and collaborators send information in?
...
Outbound Communication
Which commands, events or queries go out?
...
Ubiquitous Language
Which local terms and definitions apply?
...
Business Decisions
Which domain rules or policies apply?
...
Assumptions
Which model assumptions are unverified?
...
Verification Metrics
Which signals test whether the context boundary fits?
...
Open Questions
What remains open and who will investigate?
...
Bounded Context Canvas · DDD Crew
Name: Name context and responsibility
Expected artifact: Context name and purpose
Context name and purpose
Entry:
...
- Is the boundary justified by domain responsibility?
Language: Capture language and model
Expected artifact: Ubiquitous language and core model
Ubiquitous language and core model
Entry:
...
- Do domain experts understand every term alike?
Interface: Clarify inputs and outputs
Expected artifact: Interface overview
Interface overview
Entry:
...
- Is a source of truth named for every datum?
Boundary: Review relationships and boundaries
Expected artifact: Context canvas with resolved and open points
Context canvas with resolved and open points
Entry:
...
- Are dependencies and translations explicit?
Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/bounded-context-canvas/run-sheet
06
Example output
Concrete filled scenario, fictional example
Fictional example for orientation. Counts and timings describe this case and are not universal requirements.
bounded-context-canvas-beispiel.md
Concrete filled scenario, fictional example
Fictional, “Scheduling” context: responsibility: offer and confirm bookable times. Language: slot = period released by the practice; appointment = confirmed booking. Input: patient and practice IDs, requested period. Output: confirmed booking or rejection. Neighbours: practice management provides availability; notifications receive confirmed appointments. Open boundary: which system owns cancellation status?
07
Pitfalls
Recognize symptoms and steer against them
Quick overview, the full text is in the matching phase in the flow
- Name context and responsibilityThe boundary follows existing code or team structure alone.View in phase
- Capture language and modelA term is assumed to mean the same model across contexts.View in phase
- Clarify inputs and outputsData flows lack an owner or contract.View in phase
- Review relationships and boundariesThe canvas is treated as a binding team topology.View in phase
Trap
Name context and responsibility
Symptom
The boundary follows existing code or team structure alone.
What to do
Inspect language, rules and reasons for change before allocation.
Trap
Capture language and model
Symptom
A term is assumed to mean the same model across contexts.
What to do
Document context-specific definitions and translations.
Trap
Clarify inputs and outputs
Symptom
Data flows lack an owner or contract.
What to do
Add source, recipient and failure responsibility.
Trap
Review relationships and boundaries
Symptom
The canvas is treated as a binding team topology.
What to do
Separate model boundary from team decision and validate each.
08
Stop criteria
When to pause, resolve prerequisites, or choose another approach
Stop if the decision question or scope is disputed; align it first.
Stop if key inputs are unavailable; list what evidence is needed.
Stop if the group treats assumptions as observed facts.
Finished the method guide?
Go to the profile for purpose, similar methods, and sources or continue to the next method in the catalog.