methodatlas
Session Builder

Plan my session

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

Method session2-6 hWorkshop or asyncEvent Model

Session: Event Modeling

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 2-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 Event Model. After the session, the artifact should be shareable, reviewable, or reusable.

  1. 1

    Phase 1: Wireframes or UI sketches

    20-40 min

    Attach UI step sketches or wireframes of the scenario in the top swimlane. One image per step, arranged chronologically left to right. Hint: Wireframes can be pencil sketches; details do not matter. What matters is which information the user sees when, and which action they trigger.

    FacilitatorEvent Model
  2. 2

    Phase 2: Commands from user intent

    30-45 min

    Place one command (blue) in the middle lane directly under each UI action. Use imperative command names ("PlaceOrder", "CancelReservation"). Hint: If a UI element does not trigger a command, it is read-only. If a command has no UI trigger, it is system-triggered (scheduler, external event).

    FacilitatorUI Flow
  3. 3

    Phase 3: Events following commands

    30-45 min

    Place one or more events (orange) to the right of each command. Event names should be past tense ("OrderPlaced", "ReservationCancelled"). Draw explicit command → event relations. Hint: A command can create multiple events or fail (failure events). Model failure events explicitly, do not omit them implicitly.

    FacilitatorCommands
  4. 4

    Phase 4: Read models and state

    30-45 min

    Bottom lane: identify which data is shown on each UI screen. Derive read models (light blue) and connect them to events that update them. Hint: Read models derive from events, not from tables. If a read model cannot be derived from events, either an event is missing or the read model is cut incorrectly.

    FacilitatorRead Models
  5. 5

    Phase 5: Slices and implementation plan

    30-45 min

    Create vertical slices through the board: one slice equals one user step with command, events, read model update, and UI display. Estimate and prioritize each slice. Hint: Vertical slicing enables incremental delivery. Teams that cut horizontally (all commands, then all events) deliver no user value until the end.

    OwnerEvent Model
  6. 6

    Publish artifact

    10 min

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

    OwnerEvent Model
Usable artifact

Session Brief

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

session-brief.md

Session Brief: Event Modeling

Goal

Artifact: Event Model

Working Question

Which events, commands, and read models cover the chosen user flow end-to-end, and how can we slice implementation from this?

Context

Concrete scenario ("From cart to paid order"); pivotal events from EventStorming; existing UI mockups or screens; known read models or reports.

Setup

  • Format: Method session
  • Duration: 2-6 h
  • Mode: Workshop or async
  • Participants: One facilitator with Event Modeling experience; one to two domain experts; two to four engineers; optional UX representative for wireframes.
  • Owner: One facilitator with Event Modeling experience
  • 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 Event Model. After the session, the artifact should be shareable, reviewable, or reusable.

Input

Long board (at least 4 m or digital with zoom), horizontal swimlanes (UI/wireframes at top, commands and events middle, read models and state at bottom); orange stickies for events, blue for commands, light blue for read models, yellow for user intent or triggers; markers.

Preparation

Set up board with time axis left to right. Mark three swimlanes (UI/wireframes, Behavior/commands+events, Data/read models). Attach pivotal events as anchors in the middle lane.

Agenda

  1. Phase 1: Wireframes or UI sketches (20-40 min) Owner: Facilitator Action: Attach UI step sketches or wireframes of the scenario in the top swimlane. One image per step, arranged chronologically left to right. Hint: Wireframes can be pencil sketches; details do not matter. What matters is which information the user sees when, and which action they trigger. Output: Event Model

  2. Phase 2: Commands from user intent (30-45 min) Owner: Facilitator Action: Place one command (blue) in the middle lane directly under each UI action. Use imperative command names ("PlaceOrder", "CancelReservation"). Hint: If a UI element does not trigger a command, it is read-only. If a command has no UI trigger, it is system-triggered (scheduler, external event). Output: UI Flow

  3. Phase 3: Events following commands (30-45 min) Owner: Facilitator Action: Place one or more events (orange) to the right of each command. Event names should be past tense ("OrderPlaced", "ReservationCancelled"). Draw explicit command → event relations. Hint: A command can create multiple events or fail (failure events). Model failure events explicitly, do not omit them implicitly. Output: Commands

  4. Phase 4: Read models and state (30-45 min) Owner: Facilitator Action: Bottom lane: identify which data is shown on each UI screen. Derive read models (light blue) and connect them to events that update them. Hint: Read models derive from events, not from tables. If a read model cannot be derived from events, either an event is missing or the read model is cut incorrectly. Output: Read Models

  5. Phase 5: Slices and implementation plan (30-45 min) Owner: Owner Action: Create vertical slices through the board: one slice equals one user step with command, events, read model update, and UI display. Estimate and prioritize each slice. Hint: Vertical slicing enables incremental delivery. Teams that cut horizontally (all commands, then all events) deliver no user value until the end. Output: Event Model

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

Closeout

  • Update result artifact: Event Model
  • 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

Event Model: Event Modeling

Working Question

Which events, commands, and read models cover the chosen user flow end-to-end, and how can we slice implementation from this?

Context

Concrete scenario ("From cart to paid order"); pivotal events from EventStorming; existing UI mockups or screens; known read models or reports.

Participants

  • Owner: One facilitator with Event Modeling experience
  • Participants: One facilitator with Event Modeling experience; one to two domain experts; two to four engineers; optional UX representative for wireframes.

Input

Long board (at least 4 m or digital with zoom), horizontal swimlanes (UI/wireframes at top, commands and events middle, read models and state at bottom); orange stickies for events, blue for commands, light blue for read models, yellow for user intent or triggers; markers.

Template

Event Modeling Working Template

Goal

Models system behavior through Events, Commands, Views, and Policies along a scenario.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Event Model:
  • UI Flow:
  • Commands:
  • Read Models:

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

Completion Check

  • Event Model 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

Event Modeling Working Template

View templateCompact working template for Event Modeling with context, input, output artifacts, and next step.
markdown

event-modeling-working-template.md

Compact working template for Event Modeling with context, input, output artifacts, and next step.

Event Modeling Working Template

Goal

Models system behavior through Events, Commands, Views, and Policies along a scenario.

Context

When and for what do we use this method?

Input

Which data, observations, decisions, or materials are available?

Execution

Short notes along the runsheet.

Output artifacts

  • Event Model:
  • UI Flow:
  • Commands:
  • Read Models:

Assumptions and open questions

  • ...

Decision / Next step

Owner, date, and success signal.

Ready to use when
  • Working question, owner, and target artifact are visible.
  • The result fits Event Model.
  • One board entry with date per scenario. On model changes (new slices, changed events), create a new version. Keep prior versions to preserve model evolution.
  • Open questions are noted as follow-ups.
  • The next review or decision point is scheduled.
ProfileRunsheet