Move from domain flow to language, events, bounded contexts, and first architecture boundaries.
A domain-justified cut with events, terms, context boundaries, and open integration questions.
You can decide which domain boundaries, language, and integration relationships are relevant for next architectural work.
Validate boundaries with teams and stakeholders and move into architecture decisions or system slicing.
Which business events, triggers, and boundaries shape the flow, and where do friction, risk, or learning needs arise?
Event Storming makes domain events, commands, and hotspots visible in the workflow.
The event view is then grounded by actors, activities, and stories.
How do actors work toward a business outcome, including exceptions?
Domain Storytelling explains who does what with whom and brings domain language into a narratable form.
The stories help identify responsibilities and possible context boundaries.
Where should this domain boundary sit, and how will contexts collaborate?
Bounded Context Canvas specifies purpose, language, rules, and accountability of a context.
Contexts are then mapped in relation to each other.
Which models apply where, and how do contexts influence one another when collaborating?
Context Map shows integration relationships, dependencies, and power dynamics between contexts.
The map becomes the basis for architecture decisions, team boundaries, or integration strategy.
Artifacts stay collapsed until you actually need them.
Prepare a selected step or the complete flow. Your ready-to-use plan takes shape on the right.
# EventStorming: Worksheet
## Question
To be confirmed
## Desired outcome
To be confirmed
## Scope
Entire workshop
Time: Allow 2 hours or more for a focused slice; schedule Process-Level depth separately.
Complete this worksheet on paper or in your own document during the work.
## Preparation for this scope
### Method setup
- **Materials:** Large wall or digital board with at least 8 m of horizontal space; orange sticky notes (Events), blue (Commands), yellow (Actors), pink (Hot Spots), purple (Policies), green (Read Models); markers; camera for snapshots; parking-lot area.
- **Roles:** A facilitator with EventStorming experience; three to six domain experts from business; two to four engineers or architects; one scribe for hot spots and open questions.
- **Advance information:** Gather an example story, known domain terms, relevant edge cases and existing process notes as conversation prompts. The notes start the conversation; they do not replace shared storytelling.
- **Overall time needed:** 2-8 h
- **Setup:** Prepare a large open wall or board, a visible legend, markers, event and hot-spot cards, and a parking lot for solutions. In Big Picture, introduce only the notation needed for the flow; justify a Process-Level zoom separately.
### Prepare for the work steps
#### Frame: Frame the flow and voices
- Business flow with a named start and end
- People with direct knowledge from affected areas
- Known terms and open questions
#### Events first: Collect past events
- Working frame and an example story
- Orange cards or an equivalent digital board
- Domain expertise from the participants
#### Timeline: Sharpen the timeline and breaks
- Raw event picture
- Examples of normal and unusual paths
- Markers for disagreement and friction
#### Zoom: Explore friction and boundaries
- Shared event timeline
- Observed friction, conflict and edge cases
- Perspectives on responsibility, hand-offs and language
#### Follow-up: Capture and continue
- Event timeline and boundary sketch
- Prioritized hot spots
- Decision and delivery context
## Frame: Frame the flow and voices
Expected artifact: Working frame
Scope · participants · initial glossary · missing perspectives
Entry:
...
- [ ] Can everyone say in one sentence which flow is being explored and which question should be clearer at the end?
## Events first: Collect past events
Expected artifact: Raw event picture
Event collection · rough order · marked uncertainty
Entry:
...
- [ ] Are the cards meaningful events with a relationship to time, rather than technical states, roles or desired features?
## Timeline: Sharpen the timeline and breaks
Expected artifact: Shared event timeline
Timeline · turning points · variants · open questions
Entry:
...
- [ ] Can the group explain what is agreed, where variants remain and which claim still needs observation or domain clarification?
## Zoom: Explore friction and boundaries
Expected artifact: Hot-spot and boundary sketch
Prioritized friction · boundary hypothesis · reasoned next zoom
Entry:
...
- [ ] Is each boundary or hot spot grounded in the observed flow rather than inferred only from team structure or desired architecture?
## Follow-up: Capture and continue
Expected artifact: Usable EventStorming documentation
Snapshot · timeline · glossary · owned hot spots and next actions
Entry:
...
- [ ] Could someone who was absent understand the scope, key events, uncertainty and next actions?
## Open questions and next steps
...
Method guide: https://methodatlas.meierhoff-systems.de/en/methods/event-storming/run-sheet
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](https://github.com/ddd-crew/bounded-context-canvas)
## 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