Vorher abschließenKlarer Umfang
Stimmt Gegenstand, Grenze und Entscheidung ab, bevor ihr das Modell füllt.
Ein zu breiter oder gemischter Umfang erzeugt ein irreführendes Modell.
MethodenanleitungKnowledge Modeling
Event Modeling
Die Anleitung zur Methode: Voraussetzungen und Materialien klären, den gesamten Ablauf verstehen und Ergebnisse, Stolperfallen sowie Abbruchkriterien nachschlagen.
KomplexitätMittel
Zeit2-6 h
Teilnehmende2-8
FormatWorkshop + Async
ReifegradEstablished
01
Vorbedingung
Was vorher fertig sein muss
Vorher abschließenZugang zu relevanten Belegen
Bringt Quellen und Personen mit Prozesswissen ein; trennt Fakten von Annahmen.
Ungeprüfte Deutungen wirken sonst wie gesicherte Erkenntnis.
02
Vorbereitung
Was vor Start vorliegen muss
Materialien
Gemeinsame Arbeitsfläche, Quellenbelege und eine abgestimmte Entscheidungsfrage.
Personen / Rollen
Moderation, Fachexpertise, Product, Entwicklung, Architektur.
Vorabinfos
Sammle vorhandene Daten, Beispiele, Rahmenbedingungen und relevante Perspektiven.
Zeitbedarf
2–4 Std. für einen abgegrenzten Ablauf; größere Prozesse aufteilen.
Setup
Das Team wählt ein Szenario und skizziert die relevanten Events entlang der Zeitlinie. Danach ergänzt es Commands, Read Models und UI-Reaktionen, bis der Ablauf vollständig lesbar ist. Am Ende entstehen klare Implementierungsschnitte und ein gemeinsames Bild des Systemverhaltens.
03
Kernfrage
Die eine Frage, die diese Methode beantwortet
Welche Events, Commands und Views erklären das Systemverhalten über die Zeit?
04
Ablauf
Phasen mit Ziel, Durchführung, Ergebnis und Stolperfalle
Event Modeling verbindet fachliche Abläufe mit Commands, Events und Views zu einem durchgängigen Denkmodell. Es hilft, Verhalten, UI und technische Slices aus derselben Logik heraus zu entwerfen.
Event Model: Informationsfluss
Fiktives Arbeitsbeispiel
Fiktiv, Zeitlinie Terminbuchung: Nutzer sieht verfügbare Slots → Command „Termin buchen“ → Event „Termin angefragt“ → Prüfung auf Konflikt → Event „Termin bestätigt“ oder „Buchung abgelehnt“ → Bestätigungsansicht. Read view: nächste Termine. Ausnahme: Praxis nimmt Slot parallel offline aus dem Kalender. Daraus folgt eine explizite Konfliktregel; kein Infrastrukturentscheid ist damit vorweggenommen.
| Szenario | Zeitpunkt | Command | Event | View |
|---|---|---|---|---|
| Szenario 1Beobachtung oder Beispiel für diese Zeile erfassen. | Nach Slot-Auswahl | Termin buchen | Termin bestätigt | Nächste Termine |
1. Zeitpunkt
- Szenario 1
- Nach Slot-Auswahl
2. Command
- Szenario 1
- Termin buchen
3. Event
- Szenario 1
- Termin bestätigt
4. View
- Szenario 1
- Nächste Termine
Fiktiv, Zeitlinie Terminbuchung: Nutzer sieht verfügbare Slots → Command „Termin buchen“ → Event „Termin angefragt“ → Prüfung auf Konflikt → Event „Termin bestätigt“ oder „Buchung abgelehnt“ → Bestätigungsansicht. Read view: nächste Termine. Ausnahme: Praxis nimmt Slot parallel offline aus dem Kalender. Daraus folgt eine explizite Konfliktregel; kein Infrastrukturentscheid ist damit vorweggenommen.
- 1
Szenario
Szenario und Ergebnis festlegen
Ziel
Szenario mit klaren Endzuständen
Voraussetzungen für diesen Schritt
- Nutzerziel, Systemgrenze, Ausgangszustand
Durchführung
- Wähle einen wertvollen Use Case und beschreibe, woran eine erfolgreiche oder abgelehnte Ausführung erkennbar ist.
Ergebnis
Szenario mit klaren Endzuständen
Szenario mit klaren Endzuständen
Qualitätscheck
Sind Start und Ergebnis fachlich beobachtbar?
Stolperfalle
Das Modell umfasst unverbundene Abläufe. Teile in Szenarien mit eigenem Ergebnis.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
- 2
Events
Events auf Zeitachse anordnen
Ziel
Ereigniszeitlinie
Voraussetzungen für diesen Schritt
- Fachliche Änderungen und Akteure
Durchführung
- Schreibe Events als eingetretene Fakten und ordne sie zeitlich; trenne Systemereignis von flüchtiger Interaktion.
Ergebnis
Ereigniszeitlinie
Ereigniszeitlinie
Qualitätscheck
Verändert jedes Event fachliche Information?
Stolperfalle
Commands oder Screens werden als Events bezeichnet. Formuliere das Event als abgeschlossene Zustandsänderung.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
- 3
Commands
Commands und Views ergänzen
Ziel
Command/Event/View-Modell
Voraussetzungen für diesen Schritt
- Zeitlinie, auslösende Nutzerintentionen, benötigte Screens
Durchführung
- Verknüpfe Commands mit Entscheidungen/Akteuren und Views mit den Informationen, die ein Nutzer zu diesem Zeitpunkt sieht.
Ergebnis
Command/Event/View-Modell
Command/Event/View-Modell
Qualitätscheck
Lässt sich jeder View aus vorangegangenen Änderungen erklären?
Stolperfalle
Read Model und Oberfläche bleiben lose mit Events verbunden. Zeige welche Ereignisse den View aktualisieren.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
- 4
Varianten
Varianten und Informationsfluss prüfen
Ziel
Prüfbare Modell-Slices und offene Fragen
Voraussetzungen für diesen Schritt
- Happy Path, Ablehnungen, Nebenläufigkeit und Regeln
Durchführung
- Gehe den Ablauf Schritt für Schritt durch, ergänze fachlich relevante Alternativen und prüfe Datenfluss bis zum Ergebnis; markiere offene Regeln.
Ergebnis
Prüfbare Modell-Slices und offene Fragen
Prüfbare Modell-Slices und offene Fragen
Qualitätscheck
Fehlen Konflikt- oder Ablehnungswege?
Stolperfalle
Nur der ideale Verlauf wird automatisiert umgesetzt. Modelliere eine konkrete Gegenbedingung und erwartete Anzeige.
Zeitlicher Rahmen: Zeitbedarf richtet sich nach Umfang und Beleglage; es gibt keine allgemeine Dauer.
05
Artefakt
Was am Ende rauskommt
Skizze: so sieht das Artefakt aus
Form
Event Modeling wirkt, weil es Fachereignisse, Auslöser und sichtbare Folgen in ein gemeinsames Verhaltensbild bringt. Seine Qualität steigt, wenn echte Szenarien mit Randfällen benutzt werden und Commands, Events, Views sowie Automationen als zusammenhängende Reaktion betrachtet werden. Rein mechanisches Anordnen von Karten erzeugt nur Reihenfolgen; tragfähig wird die Methode durch präzise Schnitte, die spätere Implementierung, Datenhaltung und Bedienoberfläche zugleich klären.
Versionierung / Ownership
Notiere Umfang, Datum, Beteiligte, Quellenstand und Verantwortung. Halte geänderte Annahmen samt Änderungsgrund fest.
Tool-Alternativen
- Gemeinsames Whiteboard oder Papiervorlage
- Quellen, Aufzeichnungen oder Messdaten
event-modeling-working-template.md
Bereite Entscheidung, Quellenbelege und nächste Prüfung vor.
Event Modeling: Arbeitsvorlage
Fragestellung
Noch zu klären
Gewünschtes Ergebnis
Noch zu klären
Rahmen
Methode durchführen Zeit: Siehe Zeitrahmen im Katalog; keine allgemeine Dauer.
Diese Vorlage während der Arbeit auf Papier oder in einem eigenen Dokument ausfüllen.
Vorbereitung für diesen Umfang
Methodische Grundausstattung
- Materialien: Gemeinsame Arbeitsfläche, Quellenbelege und eine abgestimmte Entscheidungsfrage.
- Rollen: Moderation, Fachexpertise, Product, Entwicklung, Architektur.
- Vorab-Infos: Sammle vorhandene Daten, Beispiele, Rahmenbedingungen und relevante Perspektiven.
- Gesamter Zeitbedarf: 2–4 Std. für einen abgegrenzten Ablauf; größere Prozesse aufteilen.
- Setup: Das Team wählt ein Szenario und skizziert die relevanten Events entlang der Zeitlinie. Danach ergänzt es Commands, Read Models und UI-Reaktionen, bis der Ablauf vollständig lesbar ist. Am Ende entstehen klare Implementierungsschnitte und ein gemeinsames Bild des Systemverhaltens.
Für die Arbeitsschritte bereitstellen
Szenario: Szenario und Ergebnis festlegen
- Nutzerziel, Systemgrenze, Ausgangszustand
Events: Events auf Zeitachse anordnen
- Fachliche Änderungen und Akteure
Commands: Commands und Views ergänzen
- Zeitlinie, auslösende Nutzerintentionen, benötigte Screens
Varianten: Varianten und Informationsfluss prüfen
- Happy Path, Ablehnungen, Nebenläufigkeit und Regeln
Event Model: Informationsfluss
| Szenario | Zeitpunkt | Command | Event | View |
|---|---|---|---|---|
| Szenario 1 |
- Szenario 1: Beobachtung oder Beispiel für diese Zeile erfassen.
Events beschreiben Informationsänderungen; Commands drücken Absicht aus; Views zeigen Nutzerinformationen.
Szenario: Szenario und Ergebnis festlegen
Erwartetes Artefakt: Szenario mit klaren Endzuständen
Szenario mit klaren Endzuständen
Eintrag:
...
- Sind Start und Ergebnis fachlich beobachtbar?
Events: Events auf Zeitachse anordnen
Erwartetes Artefakt: Ereigniszeitlinie
Ereigniszeitlinie
Eintrag:
...
- Verändert jedes Event fachliche Information?
Commands: Commands und Views ergänzen
Erwartetes Artefakt: Command/Event/View-Modell
Command/Event/View-Modell
Eintrag:
...
- Lässt sich jeder View aus vorangegangenen Änderungen erklären?
Varianten: Varianten und Informationsfluss prüfen
Erwartetes Artefakt: Prüfbare Modell-Slices und offene Fragen
Prüfbare Modell-Slices und offene Fragen
Eintrag:
...
- Fehlen Konflikt- oder Ablehnungswege?
Offene Fragen und nächste Schritte
...
Methodenanleitung: https://methodatlas.meierhoff-systems.de/de/methods/event-modeling/run-sheet
06
Beispielausgabe
Konkret gefülltes Szenario, fiktives Beispiel
Fiktives Beispiel zur Orientierung. Die genannten Mengen und Zeiten beschreiben diesen Fall und sind keine allgemeine Vorgabe.
event-modeling-beispiel.md
Konkret gefülltes Szenario, fiktives Beispiel
Fiktiv, Zeitlinie Terminbuchung: Nutzer sieht verfügbare Slots → Command „Termin buchen“ → Event „Termin angefragt“ → Prüfung auf Konflikt → Event „Termin bestätigt“ oder „Buchung abgelehnt“ → Bestätigungsansicht. Read view: nächste Termine. Ausnahme: Praxis nimmt Slot parallel offline aus dem Kalender. Daraus folgt eine explizite Konfliktregel; kein Infrastrukturentscheid ist damit vorweggenommen.
07
Stolperfallen
Symptome erkennen, gegensteuern
Kurzüberblick, vollständiger Text steht in der jeweiligen Phase im Ablauf
- Szenario und Ergebnis festlegenDas Modell umfasst unverbundene Abläufe.In der Phase ansehen
- Events auf Zeitachse anordnenCommands oder Screens werden als Events bezeichnet.In der Phase ansehen
- Commands und Views ergänzenRead Model und Oberfläche bleiben lose mit Events verbunden.In der Phase ansehen
- Varianten und Informationsfluss prüfenNur der ideale Verlauf wird automatisiert umgesetzt.In der Phase ansehen
Falle
Szenario und Ergebnis festlegen
Symptom
Das Modell umfasst unverbundene Abläufe.
Was tun
Teile in Szenarien mit eigenem Ergebnis.
Falle
Events auf Zeitachse anordnen
Symptom
Commands oder Screens werden als Events bezeichnet.
Was tun
Formuliere das Event als abgeschlossene Zustandsänderung.
Falle
Commands und Views ergänzen
Symptom
Read Model und Oberfläche bleiben lose mit Events verbunden.
Was tun
Zeige welche Ereignisse den View aktualisieren.
Falle
Varianten und Informationsfluss prüfen
Symptom
Nur der ideale Verlauf wird automatisiert umgesetzt.
Was tun
Modelliere eine konkrete Gegenbedingung und erwartete Anzeige.
08
Abbruchkriterien
Wann du anhalten, Voraussetzungen klären oder einen anderen Ansatz wählen solltest
Stoppe, wenn Frage oder Umfang strittig sind; stimmt sie zuerst ab.
Stoppe bei fehlenden Kerndaten und notiere den Evidenzbedarf.
Stoppe, wenn Annahmen als beobachtete Fakten behandelt werden.
Methodenanleitung durchgearbeitet?
Zum Steckbrief für Zweck, ähnliche Methoden und Quellen oder direkt zur nächsten Methode im Katalog.