Meine Session planen

# 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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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). Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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. Sammle Beiträge sichtbar, gleiche Annahmen im Team ab und halte Dissens nicht nur mündlich fest. Arbeite direkt im Zielartefakt, statt nur über das Artefakt zu sprechen.
   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.

# 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 Run Sheets.

## 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