methodatlas
Session Builder

Meine Session planen

Plane einen konkreten Arbeitsblock mit Agenda, Rollen, Vorbereitung und kopierbarem Ergebnisartefakt.

Methoden-Session2-6 hWorkshop oder asyncEvent Model

Session: Event Modeling

Der Plan übersetzt die Methode in einen konkreten moderierten Arbeitsblock. Die Eingaben fließen direkt in Session Brief und Arbeitsartefakt.

Automatisch abgeleitet

Methoden-Session mit 2-8. Der Plan nutzt die vorhandene Methodenlogik und das Runsheet.

Runsheet
Beteiligungslogik
Teamrunde, gemeinsames Arbeiten und Alignment

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik
Artefakt fertigstellen

Die Session arbeitet direkt auf Event Model hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

  1. 1

    Phase 1: Wireframes oder UI-Skizzen

    20-40 min

    In der oberen Swimlane Wireframes oder Skizzen der UI-Schritte des Szenarios kleben. Pro Schritt ein Bild, links nach rechts chronologisch. Hinweis: Wireframes können Bleistift-Skizzen sein, Details egal. Was zählt: welche Information sieht der Nutzer wann, welche Aktion löst er aus.

    FacilitatorEvent Model
  2. 2

    Phase 2: Commands aus User Intent

    30-45 min

    Pro UI-Aktion einen Command (blau) in die mittlere Spur kleben, direkt unter den Wireframe. Command-Name als Imperativ („PlaceOrder“, „CancelReservation“). Hinweis: Wenn ein UI-Element keinen Command auslöst, ist es Read-only (Anzeige). Wenn ein Command keinen UI-Trigger hat, ist er System-getriggert (Scheduler, externes Event).

    FacilitatorUI Flow
  3. 3

    Phase 3: Events als Folge der Commands

    30-45 min

    Pro Command einen oder mehrere Events (orange) rechts daneben. Event-Name als Vergangenheit („OrderPlaced“, „ReservationCancelled“). Beziehung Command → Event explizit zeichnen. Hinweis: Ein Command kann mehrere Events erzeugen oder fehlschlagen (Failure Events). Failure Events explizit modellieren, nicht implizit weglassen.

    FacilitatorCommands
  4. 4

    Phase 4: Read Models und State

    30-45 min

    Untere Spur: pro UI-Bildschirm welche Daten gezeigt werden. Daraus Read Models (hellblau) ableiten und mit den Events verbinden, die sie aktualisieren. Hinweis: Read Model entsteht aus Events, nicht aus Tabellen. Wenn ein Read Model nicht aus den Events ableitbar ist, fehlt entweder ein Event oder das Read Model ist falsch geschnitten.

    FacilitatorRead Models
  5. 5

    Phase 5: Slices und Implementierungsplan

    30-45 min

    Vertikale Slices durchs Board: ein Slice = ein User-Schritt mit Command, Events, Read-Model-Update, UI-Anzeige. Pro Slice Aufwand schätzen und priorisieren. Hinweis: Vertikale Slices ermöglichen schrittweise Auslieferung. Wer horizontal schneidet (erst alle Commands, dann alle Events), liefert keinen User Value bis ganz am Ende.

    OwnerEvent Model
  6. 6

    Artefakt veröffentlichen

    10 min

    Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen.

    OwnerEvent Model
Nutzbares Artefakt

Session Brief

Für Einladung, Board, Ticket, PR-Beschreibung oder Workshop-Notiz.

session-brief.md

Session Brief: Event Modeling

Ziel

Artefakt: Event Model

Arbeitsfrage

Welche Events, Commands und Read Models bilden den gewählten User-Flow End-to-End ab und welche Slices lassen sich daraus zur Implementierung schneiden?

Kontext

Konkretes Szenario („Vom Warenkorb zur bezahlten Bestellung“); Pivotal Events aus EventStorming; bestehende UI-Skizzen oder Screens; bekannte Read Models oder Reports.

Setup

  • Format: Methoden-Session
  • Dauer: 2-6 h
  • Modus: Workshop oder async
  • Teilnehmende: Ein Facilitator mit Event-Modeling-Erfahrung; ein bis zwei Domain-Experten; zwei bis vier Engineers; optional ein UX-Vertreter für Wireframes.
  • Owner: Ein Facilitator mit Event-Modeling-Erfahrung
  • Beteiligungsmodus: Teamrunde, gemeinsames Arbeiten und Alignment
  • Ergebnislogik: Artefakt fertigstellen

Beteiligungslogik

Nutze die Session für gemeinsames Verständnis. Beiträge werden sichtbar gesammelt, Annahmen werden abgeglichen und offene Unterschiede bleiben im Artefakt nachvollziehbar.

Ergebnislogik

Die Session arbeitet direkt auf Event Model hin. Das Artefakt soll nach der Session teilbar, reviewbar oder weiterverwendbar sein.

Input

Langes Board (mindestens 4 m oder digital mit Zoom), horizontale Swimlanes (UI/Wireframes oben, Commands und Events Mitte, Read Models und State unten); orange Stickies für Events, blau für Commands, hellblau für Read Models, gelb für User Intent oder Trigger; Marker.

Vorbereitung

Board mit Zeitachse links nach rechts. Drei Swimlanes markieren (UI/Wireframes, Behavior/Commands+Events, Data/Read Models). Pivotal Events vorab in die mittlere Spur kleben als Ankerpunkte.

Agenda

  1. Phase 1: Wireframes oder UI-Skizzen (20-40 min) Owner: Facilitator Aktion: In der oberen Swimlane Wireframes oder Skizzen der UI-Schritte des Szenarios kleben. Pro Schritt ein Bild, links nach rechts chronologisch. Hinweis: Wireframes können Bleistift-Skizzen sein, Details egal. Was zählt: welche Information sieht der Nutzer wann, welche Aktion löst er aus. Output: Event Model

  2. Phase 2: Commands aus User Intent (30-45 min) Owner: Facilitator Aktion: Pro UI-Aktion einen Command (blau) in die mittlere Spur kleben, direkt unter den Wireframe. Command-Name als Imperativ („PlaceOrder“, „CancelReservation“). Hinweis: Wenn ein UI-Element keinen Command auslöst, ist es Read-only (Anzeige). Wenn ein Command keinen UI-Trigger hat, ist er System-getriggert (Scheduler, externes Event). Output: UI Flow

  3. Phase 3: Events als Folge der Commands (30-45 min) Owner: Facilitator Aktion: Pro Command einen oder mehrere Events (orange) rechts daneben. Event-Name als Vergangenheit („OrderPlaced“, „ReservationCancelled“). Beziehung Command → Event explizit zeichnen. Hinweis: Ein Command kann mehrere Events erzeugen oder fehlschlagen (Failure Events). Failure Events explizit modellieren, nicht implizit weglassen. Output: Commands

  4. Phase 4: Read Models und State (30-45 min) Owner: Facilitator Aktion: Untere Spur: pro UI-Bildschirm welche Daten gezeigt werden. Daraus Read Models (hellblau) ableiten und mit den Events verbinden, die sie aktualisieren. Hinweis: Read Model entsteht aus Events, nicht aus Tabellen. Wenn ein Read Model nicht aus den Events ableitbar ist, fehlt entweder ein Event oder das Read Model ist falsch geschnitten. Output: Read Models

  5. Phase 5: Slices und Implementierungsplan (30-45 min) Owner: Owner Aktion: Vertikale Slices durchs Board: ein Slice = ein User-Schritt mit Command, Events, Read-Model-Update, UI-Anzeige. Pro Slice Aufwand schätzen und priorisieren. Hinweis: Vertikale Slices ermöglichen schrittweise Auslieferung. Wer horizontal schneidet (erst alle Commands, dann alle Events), liefert keinen User Value bis ganz am Ende. Output: Event Model

  6. Artefakt veröffentlichen (10 min) Owner: Owner Aktion: Artefakt auf Vollständigkeit prüfen, Ablageort festlegen, Version oder Status setzen und Review-Empfänger benennen. Output: Event Model

Abschluss

  • Ergebnisartefakt aktualisieren: Event Model
  • Ablageort, Version und Review-Empfänger festlegen.
  • Owner, nächster Schritt und Reviewtermin festlegen.
Nutzbares Artefakt

Arbeitsartefakt

Vorgefüllter Startpunkt auf Basis der passenden Vorlage.

arbeitsartefakt.md

Event Model: Event Modeling

Arbeitsfrage

Welche Events, Commands und Read Models bilden den gewählten User-Flow End-to-End ab und welche Slices lassen sich daraus zur Implementierung schneiden?

Kontext

Konkretes Szenario („Vom Warenkorb zur bezahlten Bestellung“); Pivotal Events aus EventStorming; bestehende UI-Skizzen oder Screens; bekannte Read Models oder Reports.

Beteiligte

  • Owner: Ein Facilitator mit Event-Modeling-Erfahrung
  • Teilnehmende: Ein Facilitator mit Event-Modeling-Erfahrung; ein bis zwei Domain-Experten; zwei bis vier Engineers; optional ein UX-Vertreter für Wireframes.

Input

Langes Board (mindestens 4 m oder digital mit Zoom), horizontale Swimlanes (UI/Wireframes oben, Commands und Events Mitte, Read Models und State unten); orange Stickies für Events, blau für Commands, hellblau für Read Models, gelb für User Intent oder Trigger; Marker.

Vorlage

Event Modeling Arbeitsvorlage

Ziel

Modelliert Systemverhalten über Events, Commands, Views und Policies entlang eines Szenarios.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

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

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Fertigstellungscheck

  • Event Model ist vollständig genug für Review:
  • Ablageort:
  • Version / Status:
  • Review durch:
  • Nächster Schritt:

Nächster Schritt

  • Ergebnis prüfen
  • offene Fragen markieren
  • Review oder Entscheidung terminieren
Vorlagenbasis

Event Modeling Arbeitsvorlage

Vorlage ansehenKompakte Arbeitsvorlage für Event Modeling mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.
markdown

event-modeling-working-template.md

Kompakte Arbeitsvorlage für Event Modeling mit Kontext, Input, Ergebnisartefakten und nächstem Schritt.

Event Modeling Arbeitsvorlage

Ziel

Modelliert Systemverhalten über Events, Commands, Views und Policies entlang eines Szenarios.

Kontext

Wann und wofür nutzen wir diese Methode?

Input

Welche Daten, Beobachtungen, Entscheidungen oder Materialien liegen vor?

Durchführung

Kurze Notizen entlang des Runsheets.

Ergebnisartefakte

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

Annahmen und offene Fragen

  • ...

Entscheidung / Nächster Schritt

Owner, Datum und Erfolgssignal.

Direkt nutzbar, wenn
  • Arbeitsfrage, Owner und Zielartefakt sind sichtbar.
  • Das Ergebnis passt zu Event Model.
  • Pro Szenario eigener Board-Eintrag mit Datum. Bei Änderungen am Modell (neue Slices, geänderte Events) neue Version. Alte Versionen behalten zur Historie der Modell-Evolution.
  • Offene Fragen sind als Follow-up notiert.
  • Der nächste Review oder Entscheidungspunkt ist terminiert.
SteckbriefRunsheet