The steps of a session
Six stages take a business process from a first idea to slices that teams can build.
After this page, you can:
- list the six stages of a modeling session in order
- say what each stage asks, what it produces, and when it is done
- start a session at the first step that is not done
Six stages, one short form
The short form of the method is: Events, then Commands and Screens, then Read Models, then scenarios, then slices. The full method has twelve steps. This page groups them into six stages.
| Stage | Key question | You produce | Done when |
|---|---|---|---|
| 1. Scope and roles | Which process, which goal, and who acts? | A short scope and a Role Catalog. | Every role has a domain name, what it can do, and what it cannot do. |
| 2. Events and their order | Which facts happen, and in which order? | Past-tense Events in named chapters, in causal order. | Every Event is in a named chapter and has a clear trigger. |
| 3. Screens, Commands, Automations | What does each person decide? What does the system do alone? | Screens, Commands with one issuer each, Automations with todo lists. | Every human role has a Screen. Every Automation has a todo list. |
| 4. Read Models and owners | Which questions do people and Automations ask? Who owns what? | Read Models, each with one question. Team boundaries. | Every Screen has the data it needs. No Read Model answers two questions. |
| 5. Scenarios and checks | Which rules and failures must hold? Is the data complete? | Scenarios, a field check, and a review verdict. | Every Command and Read Model has scenarios. The review passes. |
| 6. Slices and reasons | Which pieces will teams build? Why did we choose this? | One slice for each Command, Read Model, and Automation. Short notes on the reasons. | No element lacks a slice. |
Stage 1: roles
Write the Role Catalog first. It lists every human role and every system actor. Examples of human roles are Clinic Staff and Owner. An example of a system actor is a Weather Provider.
Each entry has four parts:
- a domain name, not a label such as "User Type B"
- one line that says what the role does
- the actions that change state
- what the role cannot do
For a system actor, also note whether it is internal or external and how it delivers facts.
Ask the domain expert four kinds of question:
- Is the requirement written down, or only in people's heads?
- Who knows the domain, and who decides?
- Where is the risk? What can go wrong?
- Which rules apply? For example, "cancel within 24 hours". What shows that someone broke the rule?
Stage 2: Events, a worked example
Look for facts in four places: state changes, milestones, decisions with an outcome, and handoffs between people or systems. Skip implementation steps. Then put the Events in causal order. For each Event, write what must be true first and what triggers it.
In this example, the clinic has four Events:
| Event | Comes after | Trigger |
|---|---|---|
| Owner Registered | Nothing. It starts the story. | The owner registers. |
| Pet Added | Owner Registered | Staff add the pet. |
| Appointment Added | Pet Added | Staff schedule the visit. |
| Weather Predicted for Appointment | Appointment Added | The weather Automation. |
Show alternatives too, not only the happy path. For example, add a branch for a canceled appointment. Put each Event in one column. Do not skip any Event.
Assign every Event to a named chapter before you plot it. A chapter is one story. It belongs naturally to one team or one domain expert.
Try first: Appointment Added and Appointment Canceled both belong to the story of one appointment. Do they need two chapters?
Show the answer
No. A cancellation decides how the story ends. It does not start a different story. Keep both Events in one chapter. Use a separate chapter only when the person chooses a different journey before the process starts.
Stage 3: Screens, Commands, Automations
For each state on the timeline, sketch the Screen. Ask: "What decision does the person make with this data?" List each field that the Screen shows and the Event that it comes from.
Then write one Command for each action on a Screen. For each Command, write:
- the role that issues it
- its typed inputs and where each input comes from
- the earlier facts that must hold
- the Event it records, and each failure it can have
Where no person acts, place an Automation and its todo list. If an Event from another system already exists, do not place a local Command in its column. Translate the outside Event first.
Stages 4 to 6 in short
Stage 4: list each Screen and each Automation. Find the data each one needs. Write one Read Model for each question. Trace each field to an Event. Then find the owner of each Event and Command. A team owns the parts that it can change alone.
Stage 5: write scenarios for each Command and Read Model (page 5). Check that every field has an origin and a use. Then review the whole model and give it a verdict: pass, pass with warnings, or fail (page 6).
Stage 6: write one slice for each Command, Read Model, and Automation. Add a short note where a later reader can misunderstand a choice. At the end, write one note for each chapter. Say what you assumed and why.
Where to start
A model is often half done. Enter the method at the first step that is not done. Do not repeat the steps that are done.
After each step, write two to four bullets: what you made, what you decided, and what the next step must carry forward. Also list the open questions.
Do not cut a required part to save effort. A todo list, a Read Model, and a translation chain are required. If the layout is hard, solve the layout. If you must reduce the scope, say so in the notes.
Check yourself
Which comes first in a session: Screens or Events?
Answer
Events. Brainstorm and order the Events first. Sketch Screens after the Events are in order.
The Role Catalog lists one role: User. What do you change?
Answer
Replace it with specific domain roles. Give each one a name, what it can do, and what it cannot do.
Stage 3 is done, and a teammate asks to start again at stage 1. What do you do?
Answer
Enter at the first step that is not done. Repeat a done step only if a new fact shows that it was wrong.
A human role has no Screen and no Read Model. What does this tell you?
Answer
Something is missing, or the role is only decoration. Every human role needs at least one Screen and at least one Read Model.
Remember:
- The short form is Events, Commands and Screens, Read Models, scenarios, slices.
- Write the Role Catalog first, and use specific roles.
- Enter at the first step that is not done.
- Each stage has a clear check that tells you it is done.