NCA Social Media
Erstellt:
Aktualisiert:
Autor:
Roland Golla
Gelber Schriftzug Event Storming über grünem Prozesspfeil mit vier Stationen

Event Storming: Definition und Einordnung

Event Storming ist eine Workshop Methode, bei der Fachbereich und Entwicklung einen Geschäftsprozess gemeinsam als Folge von Ereignissen an eine lange Wand kleben. Jedes Ereignis steht in der Vergangenheitsform auf einem orangen Klebezettel, zum Beispiel „Bestellung aufgegeben“ oder „Zahlung eingegangen“.
Erfunden hat die Methode Alberto Brandolini im Jahr 2013, im Umfeld von Domain Driven Design. Die offizielle Schreibweise ist EventStorming in einem Wort. Gesucht wird meist nach Event Storming, gemeint ist dasselbe.
Das Ziel ist gemeinsames Verstehen. Wer an der Wand steht, sieht Lücken, Widersprüche und offene Fragen, bevor sie im Code landen. Aus dem Ergebnis entstehen später eine Ubiquitous Language, sauber geschnittene Bounded Contexts und bei Bedarf die Basis für Event Sourcing oder CQRS.
Inhalt
NCA KI Workshop für Developer

Agentic Coding im Team, nicht nur im Glossar

Ein Tag inhouse mit Benjamin Klein für Developer, Tester und Admins. Context Engineering, Harness, ADRs und zwei Hands on Blöcke mit KI Agenten in eurem Setup.

  1. 1
    Kostenloses Vorgespräch
    Stand, Rollen und Ziele klären
  2. 2
    Workshoptag bei euch
    Praxis am Vormittag, Hands on danach
  3. 3
    Praxistag optional
    Agenten im eigenen Projekt
Benjamin Klein
Benjamin Klein
Senior Consultant
Zum Workshop für Developer arrow_forward

Event Storming mit NCA: Schnelle Hilfe vom Experten

Bevor wir fachliche Grenzen im Code ziehen, klären wir die Fachlichkeit mit allen Beteiligten. Never Code Alone baut täglich mit Symfony und Sulu CMS. Event Storming ist dafür ein leichtes Werkzeug: eine Wand, Klebezettel und die richtigen Leute im Raum. Das Ergebnis übersetzen wir in Bounded Contexts und sichern es mit Deptrac und PHP Arkitect in der Pipeline ab.
In gewachsenen Systemen macht die Wand das heutige Verhalten sichtbar. Danach folgen Characterization Tests, ein Anti Corruption Layer an der Grenze zum Altsystem und die schrittweise Ablösung mit dem Strangler Fig Pattern. Wie KI Agents von klar modellierten Domänen profitieren, ordnen wir bei Vibe Coding Consulting ein.

So läuft ein Event Storming ab

Ein Event Storming folgt einem einfachen Muster. Der Raum braucht viel freie Wandfläche, genug Klebezettel und eine Moderation, die selbst keine Fachexpertin ist. Alle stehen, niemand klappt den Laptop auf.
  1. Chaotische Erkundung: Alle schreiben Ereignisse auf, die ihnen einfallen. Ohne Reihenfolge, ohne Diskussion.
  2. Zeitleiste ordnen: Die Ereignisse wandern in eine zeitliche Reihenfolge. Doppelte fallen weg, Lücken werden sichtbar.
  3. Hotspots markieren: Widersprüche und offene Fragen bekommen einen pinken Zettel. Sie sind oft das wertvollste Ergebnis.
  4. Pivotal Events finden: Wenige Schlüsselereignisse teilen den Prozess in Abschnitte. Hier zeigen sich erste Kandidaten für fachliche Grenzen.
  5. Geschichten erzählen: Die Gruppe läuft die Wand von links nach rechts ab und spielt konkrete Fälle durch. Dabei tauchen Sonderfälle auf.
In der ersten Runde redet niemand über Datenbanken, Tabellen oder Klassen. Es geht nur um den Prozess. Der Code kommt später, und er wird besser, weil alle vorher dasselbe Bild im Kopf haben.

Die drei Formate: Big Picture, Process Modelling, Software Design

Brandolini unterscheidet drei Formate. Sie bauen aufeinander auf, lassen sich aber auch einzeln nutzen.
Big Picture schaut auf das ganze Geschäft oder einen großen Bereich. Viele Menschen, grobe Auflösung, wenige Regeln. Das Ergebnis ist ein gemeinsames Bild und eine Liste der größten Probleme.
Process Modelling geht in einen einzelnen Prozess. Neben Ereignissen kommen Commands, Policies, Read Models und externe Systeme dazu. Software Design führt bis zu Aggregates und liefert eine Vorlage für den Code.

Event Storming Formate im Vergleich

Format Ziel Wer ist dabei
Big Picture Gemeinsames Bild des Geschäfts, größte Probleme finden Fachbereich, Management, Entwicklung, Support
Process Modelling Einen Prozess Schritt für Schritt klären Fachexperten und Entwicklung für diesen Prozess
Software Design Aggregates, Commands und Grenzen für den Code ableiten Entwicklung mit Fachexperten

Die Farben der Klebezettel

Die Notation ist bewusst einfach. Jede Farbe steht für eine Art von Information. Teams dürfen eigene Elemente ergänzen, solange alle die Legende kennen.
  • Orange: Domain Event, ein fachliches Ereignis in der Vergangenheitsform.
  • Blau: Command, eine Aktion oder Entscheidung, die ein Ereignis auslöst.
  • Lila: Policy, eine Regel nach dem Muster „immer wenn X passiert, tun wir Y“.
  • Gelb, klein: Actor, die Person oder Rolle, die handelt.
  • Gelb, groß: Aggregate, die Einheit, die ein Command annimmt und Regeln prüft.
  • Grün: Read Model, die Information, die jemand für eine Entscheidung braucht.
  • Pink: Hotspot für Probleme, Fragen und Widersprüche.
Die Farben unterscheiden sich je nach Quelle leicht. Wichtig ist eine sichtbare Legende an der Wand, damit niemand raten muss.

Von der Wand in den PHP Code

Ein Domain Event von der Wand wird im Code zu einer kleinen, unveränderlichen Klasse. Der Name bleibt derselbe wie auf dem Zettel. So wandert die Ubiquitous Language direkt in den Code.
Code: 
          
final readonly class BestellungAufgegeben
{
    public function __construct(
        public string $bestellId,
        public string $kundenId,
        public \DateTimeImmutable $aufgegebenAm,
    ) {
    }
}
Commands von der Wand werden zu Command Klassen, Policies zu Event Subscribern. In Symfony bietet sich der Messenger dafür an. Wer Ereignisse dauerhaft speichern will, landet bei Event Sourcing. Wer Lesen und Schreiben trennt, bei CQRS. Pflicht ist beides nicht.
Die Abschnitte an der Wand werden zu Bounded Contexts. Wie sie zueinander stehen, zeigt eine Context Map, mehr dazu bei Context Mapping. Mit Deptrac prüft die Pipeline, dass die Grenzen im Code halten.

Event Storming und KI Agents 2026

Ein KI Agent kennt eure Fachlichkeit nicht. Er kennt nur, was in seinem Kontext steht. Die Ergebnisse eines Event Storming sind dafür ideales Material: eine Liste aller Domain Events, klare Begriffe und benannte Grenzen.
Ein bewährter Weg ist eine Markdown Datei im Repository mit Events, Commands und Bounded Contexts. Coding Agents wie OpenCode lesen sie mit, bevor sie Code schreiben. Die Klasse heißt dann so wie das Ereignis an der Wand, und der Agent bleibt in seinem Bereich. Mehr dazu in den Vibe Coding Best Practices.
KI kann beim Event Storming helfen, etwa beim Abtippen der Wand oder beim Finden von Lücken in der Zeitleiste. Die Diskussion übernimmt sie nicht, das gemeinsame Verstehen passiert zwischen Menschen. Fotos der Wand zeigen oft interne Abläufe. Für die Auswertung eignen sich deshalb lokale Modelle über Ollama.

Wann sich Event Storming lohnt

Event Storming spielt seine Stärken aus, wenn viele Menschen an einem Prozess beteiligt sind und keiner das ganze Bild hat.
  • Ein neues Produkt mit unklaren Anforderungen
  • Ein Legacy System, das niemand mehr ganz versteht
  • Vor dem Schnitt eines Monolithen in Module oder Services
  • Beim Onboarding neuer Leute ins Team
  • Wenn mehrere Abteilungen an einem Ablauf hängen
Weniger passend ist die Methode für einfache CRUD Anwendungen ohne echte Fachlogik. Und ohne Fachexperten im Raum wird aus dem Workshop ein Ratespiel der Entwickler. Remote klappt es mit digitalen Whiteboards, braucht dann aber eine straffere Moderation und kürzere Blöcke.

It's developers' (mis)understanding, not domain experts' knowledge, that gets released in production.

Alberto Brandolini, Erfinder von EventStorming, Gründer von Avanscoperta – Introducing EventStorming, Leanpub

Die NCA Erfahrung mit Fachlichkeit und Code

Event Storming ist bei uns der Anfang einer Kette. Die Begriffe landen in der Ubiquitous Language, die Abschnitte werden zu Bounded Contexts, und das Context Mapping klärt, wie sie zusammenspielen. Wo es passt, folgen CQRS und Event Sourcing.
In gewachsenen Systemen sichern wir zuerst ab. Characterization Tests halten das Verhalten fest, PHPUnit, Symfony KernelTestCase und PHP Functional Tests decken die Ebenen ab, Infection prüft die Aussagekraft. Für den Umbau nutzen wir Parallel Change, Parallel Run und Feature Flags.
Die Architektur halten Werkzeuge in der Pipeline stabil: PHPStan für Typen, Rector für Umbauten, phpat und Deptrac für Grenzen. DePHPend und Churn PHP zeigen, wo die Abhängigkeiten und Änderungen sich häufen.
Weitere Begriffe stehen im NCA PHP Glossar. Wer mit KI gestützter Entwicklung startet, findet den Einstieg bei Vibe Coding lernen.
CYPRESS.IO Ambassador und IT Consultant für QA Engenieering und Qualität in PHP Projekten.
Erreichen Sie unsere PHP Consultant Spezialisten

Wir sind Experten für PHP und helfen Ihnen, Ihre digitalen Herausforderungen zu meistern. Unser erfahrenes Team unterstützt Sie bei PHP Updates, PHP Refactoring und berät Sie remote zu allen Fragen rund um PHP. Mit unseren vollautomatischen CI/CD Deployments und einer robusten Docker-Infrastruktur bringen wir Ihre PHP-Projekte auf das nächste Level. Vertrauen Sie auf unsere Expertise für zuverlässige und skalierbare PHP-Lösungen.

Demo Team Workshop Anrufen

Häufige Fragen zu Event Storming

Die wichtigsten Antworten zu Ablauf, Teilnehmenden, Werkzeugen und dem Weg von der Wand in den Code.
Was ist Event Storming 2026?

Event Storming ist eine Workshop Methode aus dem Domain Driven Design. Fachbereich und Entwicklung kleben die Ereignisse eines Geschäftsprozesses in zeitlicher Reihenfolge an eine lange Wand. So entsteht in wenigen Stunden ein gemeinsames Bild, das Lücken und Widersprüche zeigt. Alberto Brandolini hat die Methode 2013 entwickelt. Sie funktioniert für neue Produkte genauso wie für gewachsene Systeme.

Wie lange dauert ein Event Storming 2026?

Ein Big Picture Event Storming dauert meist einen halben bis ganzen Tag. Process Modelling für einen einzelnen Prozess braucht oft zwei bis drei Stunden. Entscheidend ist weniger die Zeit als die Auswahl der Leute. Remote Sessions teilt man besser in mehrere kürzere Blöcke, weil die Konzentration am Bildschirm schneller nachlässt.

Wer sollte 2026 an einem Event Storming teilnehmen?

Die Leute mit den Fragen und die Leute mit den Antworten. Also Entwicklung, Fachexperten, Product Owner und bei Bedarf Support oder Vertrieb. Wichtig ist eine neutrale Moderation. Beim Big Picture dürfen viele Menschen dabei sein, im Process Modelling bremsen zu große Gruppen. Fehlen die Fachexperten, zeigt die Wand nur Vermutungen.

Welche Werkzeuge braucht man 2026 für Event Storming?

Vor Ort reichen eine lange Papierrolle, Klebezettel in mehreren Farben und dicke Stifte. Remote nutzen Teams digitale Whiteboards mit vorbereiteten Farben und einer Legende. Wichtiger als das Werkzeug ist genug Platz. Eine zu kleine Fläche zwingt früh zu Entscheidungen und bremst die offene Erkundung am Anfang.

Wie hilft Event Storming 2026 bei KI gestützter Entwicklung?

Coding Agents kennen eure Fachlichkeit nicht. Die Ergebnisse eines Event Storming liefern ihnen klare Begriffe, eine Liste der Domain Events und benannte Grenzen. Als Markdown Datei im Repository wird daraus Kontext für jeden Prompt. Der Agent benennt Klassen dann so wie das Fachteam und arbeitet innerhalb eines klaren Bereichs.

Was ist ein Domain Event?

Ein Domain Event ist ein fachlich relevantes Ereignis, das bereits passiert ist. Es steht immer in der Vergangenheitsform, etwa „Rechnung versendet“. Beim Event Storming klebt es auf einem orangen Zettel. Im Code wird daraus eine kleine, unveränderliche Klasse. Domain Events sind die Basis für Event Sourcing, helfen aber auch ohne Event Sourcing.

Was ist der Unterschied zwischen Event Storming und Event Sourcing?

Event Storming ist eine Workshop Methode, Event Sourcing ein Architekturmuster. Beim Event Storming modelliert ein Team Prozesse als Ereignisse an der Wand. Beim Event Sourcing speichert eine Anwendung ihren Zustand als Folge von Ereignissen. Das eine führt oft zum anderen, Pflicht ist das nicht. Viele Teams nutzen Event Storming mit einer klassischen Datenbank.

Was ist ein Hotspot beim Event Storming?

Ein Hotspot markiert ein Problem, eine offene Frage oder einen Widerspruch. Er klebt meist als pinker Zettel an der Wand, damit er sofort auffällt. Hotspots sind oft das wertvollste Ergebnis, weil sie zeigen, wo Wissen fehlt oder Abteilungen verschieden denken. Nach dem Workshop werden sie priorisiert und gezielt geklärt.

Wie findet man mit Event Storming Bounded Contexts?

An der Wand zeigen sich Bereiche, in denen Begriffe ihre Bedeutung wechseln oder andere Leute zuständig sind. Pivotal Events trennen solche Abschnitte. Diese Stellen sind Kandidaten für Bounded Contexts. Sie sind ein Startpunkt, noch keine fertige Architektur. Im Process Modelling und im Code wird der Schnitt geschärft und später mit Deptrac abgesichert.

Funktioniert Event Storming auch bei Legacy Systemen?

Ja, gerade dort. Oft kennt niemand mehr den ganzen Ablauf. Die Wand macht das heutige Verhalten sichtbar, samt Umwegen und Sonderfällen. Das Ergebnis hilft beim Schreiben von Characterization Tests und bei der Planung einer schrittweisen Ablösung mit dem Strangler Fig Pattern. Umgebaut wird erst, wenn das Verhalten abgesichert ist.

Muss man Domain Driven Design kennen, um Event Storming zu nutzen?

Nein. Fachexperten brauchen gar kein Vorwissen, Entwickler nur wenig. Die Notation ist in wenigen Minuten erklärt. Wer später Bounded Contexts, Aggregates oder CQRS nutzen will, profitiert aber von DDD Grundlagen. Für viele Teams ist Event Storming der einfachste Einstieg in Domain Driven Design überhaupt.

Wie oft sollte man ein Event Storming wiederholen?

Immer dann, wenn sich das Geschäft deutlich ändert oder ein neuer Bereich entsteht. Die Wand ist eine Momentaufnahme. Viele Teams halten die Ergebnisse als Datei im Repository aktuell und machen für neue Features kurze Process Modelling Runden. So bleibt die gemeinsame Sprache nah am Code und veraltet nicht still im Wiki.