Event Storming in der Softwareplanung – warum ich es auch ohne DDD nutze

Event Storming ist für mich das effektivste Werkzeug, um ein Softwareprojekt zu verstehen, bevor ich auch nur eine Zeile Code schreibe. Nicht weil es gerade Trend ist, oder sich nach „modern“ anhört, sondern weil ich in über zehn Jahren Entwicklung keine schnellere Methode gefunden habe, um mit Fachleuten, Stakeholdern und Entwicklern ein gemeinsames Bild einer Software zu erzeugen.

Das Besondere: Ich nutze Event Storming in jedem Projekt, auch wenn ich kein Domain-Driven Design (DDD) einsetze. Warum das funktioniert und wie ein solcher Workshop in der Praxis aussieht, zeige ich in diesem Beitrag.

Wenn Entwickler und Fachseite aneinander vorbeireden

In Vorträgen, in Gesprächen mit anderen Entwicklern und in meinen eigenen Projekten höre ich dasselbe Problem immer wieder: Beide Seiten gehen davon aus, dass sie sich verstanden haben. Der Kunde nickt. Der Entwickler nickt. Und drei Monate später steht eine Software da, die technisch funktioniert, aber am eigentlichen Bedarf vorbeigeht.

Das passiert nicht aus Böswilligkeit. Es passiert, weil Entwickler in Strukturen denken, Datenmodelle, APIs, Schichten, während die Fachseite in Abläufen denkt: „Der Kunde ruft an, wir prüfen die Verfügbarkeit, dann geht eine Bestätigung raus.“ Beide beschreiben dasselbe System, aber in komplett unterschiedlichen Sprachen. Und niemand merkt es, bis es zu spät ist.

Die Kosten dafür sind real:

• Features, die gebaut, aber nie genutzt werden, weil die Anforderung anders gemeint war
• Nachbesserungen im Sprint 8, die in Sprint 1 hätten geklärt werden können
• Meetings, in denen dieselben Fragen zum dritten Mal diskutiert werden
• Frustration auf beiden Seiten, die das Vertrauen in die Zusammenarbeit zerstört

Studien beziffern den Anteil von Anforderungsfehlern an der Gesamtfehlerquote in Softwareprojekten auf 40–60 %. Die teuersten Bugs sind nicht die, die im Code stecken, sondern die, die im Verständnis stecken.

Event Storming löst genau dieses Problem. Nicht mit besseren Dokumenten, nicht mit längeren Meetings, sondern mit einer Methode, die beide Seiten zwingt, über dasselbe zu reden, sichtbar, gleichzeitig und ohne Interpretationsspielraum.

Was ist Event Storming?

Event Storming ist eine Workshop-Methode, entwickelt von Alberto Brandolini. Die Grundidee ist simpel: Du klebst orangefarbene Sticky Notes an eine Wand, jedes Sticky beschreibt ein Ereignis, das in deinem System passiert. „Bestellung aufgegeben“, „Rechnung erstellt“, „Nutzer registriert“.

Kein UML. Keine Diagramme. Keine Tooling-Diskussionen. Stattdessen stehen alle Beteiligten, Entwickler, Fachexperten, Projektleiter, gemeinsam vor einer Wand und sprechen über das, was tatsächlich passiert.

Und genau das macht die Methode so wirkungsvoll: Sie zwingt dazu, über Verhalten zu reden statt über Datenbanktabellen oder Klassendiagramme. In meiner Erfahrung tauchen dabei regelmäßig Annahmen auf, die seit Monaten unausgesprochen im Raum standen und die niemand hinterfragt hat.

Event Storming Farben und ihre Bedeutung

Die verschiedenen Sticky-Note-Farben sind kein Zufall, jede Farbe hat eine feste Bedeutung. Das Farbsystem sorgt dafür, dass ein volles Whiteboard trotzdem lesbar bleibt:

• 🟧 Orange — Domain Event: Etwas, das passiert ist. Immer in Vergangenheitsform formuliert. „Bestellung wurde aufgegeben“, „Zahlung eingegangen“. Das ist der Kern von Event Storming.
• 🟦 Blau — Command: Eine Aktion, die jemand oder etwas auslöst. „Bestellung aufgeben“, „Konto sperren“. Commands lösen Events aus.
• 🟨 Gelb — Actor / Benutzer: Wer löst den Command aus? Ein Mensch, ein System, ein Timer?
• 🟪 Lila / Pink — Policy / Regel: Automatisierte Reaktionen. „Wenn Zahlung eingegangen, dann Rechnung erstellen.“ Policies verbinden Events mit Commands.
• 🟩 Grün — Read Model / Information: Welche Daten braucht der Actor, um eine Entscheidung zu treffen?
• 🟥 Rot — Problem / Hotspot: Offene Fragen, Konflikte, Unklarheiten. Alles, was noch geklärt werden muss.
• ⬜ Weiß — Externes System: Systeme außerhalb deiner Kontrolle: Payment-Provider, E-Mail-Dienst, ERP.

Am Anfang wirkt das wie viel. In der Praxis hat man die Farben nach 15 Minuten verinnerlicht und sie werden zum gemeinsamen Vokabular des Teams.

So läuft ein Event Storming Workshop ab

Ich habe Event Storming Workshops mit drei Personen durchgeführt und mit fünfzehn. Der Ablauf ist im Kern immer gleich:

Phase 1: Chaotische Exploration

Alle kleben gleichzeitig orangefarbene Stickies an die Wand, jedes Ereignis, das ihnen einfällt. Ohne Reihenfolge, ohne Diskussion. Das dauert 15–20 Minuten und fühlt sich bewusst chaotisch an. Genau das ist gewollt: Es senkt die Hemmschwelle und bringt Dinge ans Tageslicht, die in klassischen Meetings untergehen.

Phase 2: Timeline sortieren

Jetzt wird geordnet. Die Stickies kommen in eine zeitliche Reihenfolge, von links nach rechts. Dabei fallen sofort Lücken auf. „Was passiert eigentlich zwischen Bestelleingang und Versand?“ Genau diese Lücken sind Gold wert.

Phase 3: Anreichern

Jetzt kommen die anderen Farben ins Spiel: Commands, Actors, Policies, Externe Systeme. Die Wand wird dichter, aber auch klarer. Man sieht plötzlich, wo die eigentliche Komplexität steckt und das ist selten dort, wo man sie vermutet hat.

Phase 4: Hotspots markieren

Alles, was unklar ist oder wo zwei Personen widersprüchliche Aussagen gemacht haben, bekommt ein rotes Sticky. Keine sofortige Klärung nötig, aber sichtbar gemacht. In klassischen Meetings werden solche Widersprüche überhört. An einer physischen Wand kann man sie nicht ignorieren.

Ein typischer Workshop dauert bei mir zwischen 2 und 4 Stunden. Für die meisten Projekte reicht ein einziger Workshop, um das Gesamtbild zu erfassen. Bei größeren Systemen teile ich in mehrere Sessions auf, pro Fachbereich oder Subdomain.

Event Storming ohne DDD – warum das funktioniert

Wenn man „Event Storming“ googelt, landet man sofort bei Domain-Driven Design. Aggregates, Bounded Contexts, Ubiquitous Language – das volle Programm. Und ja, Event Storming wurde ursprünglich als Werkzeug für DDD entwickelt.

Aber ehrlich gesagt: In den meisten Projekten, in denen ich arbeite, setze ich kein DDD ein. Keine Aggregates, keine Repositories im DDD-Sinne, kein CQRS. Trotzdem nutze ich Event Storming und zwar bei jedem Projekt, das über ein simples CRUD-Formular hinausgeht.

Warum? Weil der eigentliche Wert von Event Storming nicht in der DDD-Modellierung liegt. Er liegt in drei Dingen:

1. Gemeinsames Verständnis schaffen. Entwickler und Fachexperten reden endlich über die gleichen Abläufe, nicht über unterschiedliche Interpretationen einer Anforderungsliste.
2. Komplexität sichtbar machen. Auf einer physischen Wand sieht man sofort, wo es hakt. Welcher Prozess hat zwanzig Schritte? Wo gibt es drei verschiedene Ausnahmen? Das erkennt man in keinem Pflichtenheft.
3. Entscheidungen vorziehen. Statt im Sprint 5 festzustellen, dass ein Requirements-Widerspruch existiert, findest du ihn im Workshop, bevor eine Zeile Code geschrieben wurde.

Ich nehme aus dem Event Storming dann das mit, was ich brauche: Ablauflogik, Zuständigkeiten, Systemgrenzen. Ob ich das anschließend in eine klassische Schichtenarchitektur oder in eine DDD-orientierte Struktur gieße, entscheide ich danach, nicht davor.

Ein Event Storming Beispiel aus der Praxis

Vor einigen Monaten kam ein Unternehmen auf mich zu, das seine interne Auftragsverwaltung modernisieren wollte. WinForms-Anwendung, über zehn Jahre gewachsen, unzählige Sonderfälle. Drei verschiedene Abteilungen nutzten die Software, jede mit einer eigenen Vorstellung davon, wie ein Auftrag aussieht.

Statt direkt in Code zu springen, habe ich einen halbtägigen Event Storming Workshop vorgeschlagen. Die Teilnehmer: ein Vertriebskollege, eine Person aus der Buchhaltung, der Lagerleiter und ich.

Ergebnis nach drei Stunden:

• Wir hatten 47 Domain Events identifiziert — von „Anfrage erhalten“ bis „Auftrag archiviert“.
• Es gab 6 rote Hotspots — Stellen, an denen die Abteilungen widersprüchliche Abläufe beschrieben hatten. Sechs Konflikte, die in keinem bisherigen Meeting aufgefallen waren.
• Der Vertrieb und die Buchhaltung hatten unterschiedliche Definitionen von „abgeschlossener Auftrag“. Der eine meinte: Ware versendet. Die andere: Rechnung bezahlt. Dieser eine Unterschied hätte im Code zu einem Bug geführt, der erst nach Wochen aufgefallen wäre.

Kein DDD. Keine Aggregates. Einfach Menschen vor einer Wand mit Stickies. Und das Ergebnis war eine Klarheit, die ich mit keinem Pflichtenheft je erreicht habe.

Wann sich Event Storming lohnt – und wann nicht

Event Storming ist kein Allheilmittel. Für eine simple CRUD-Anwendung mit fünf Formularen braucht man keinen Workshop. Da reicht ein Gespräch und ein Notizbuch.

✅ Es lohnt sich, wenn:

• Mehrere Fachbereiche oder Stakeholder beteiligt sind
• Die Abläufe komplex sind oder viele Sonderfälle existieren
• Es ein bestehendes System gibt, das niemand mehr vollständig versteht
• Entscheidungen über Architektur oder Technologie anstehen
• Bisherige Anforderungsdokumente zu Missverständnissen geführt haben

❌ Es lohnt sich nicht, wenn:

• Das Projekt trivial ist (wenige Entities, kein Workflow)
• Nur ein Entwickler beteiligt ist und die Fachlichkeit selbst kennt
• Die Stakeholder nicht bereit sind, 2–3 Stunden zu investieren

Gerade den letzten Punkt meine ich ernst. Event Storming lebt von der Beteiligung der Fachseite. Wenn der Workshop nur aus Entwicklern besteht, verpasst man den größten Vorteil, nämlich das Aufdecken von implizitem Wissen, das in keinem Dokument steht.

Mein eigenes Event Storming Portal für Kundenprojekte

Die meisten Freelancer reden über Event Storming. Ich habe mir ein eigenes kleines Portal dafür gebaut. Als Bestandteil meiner allgemeinen Projektverwaltungssoftware.

Warum? Weil ich in der Praxis immer wieder an denselben Punkt kam: Der Workshop war produktiv, die Wand voller Stickies, alle hatten ein gemeinsames Bild. Und dann? Fotos vom Whiteboard, die nach zwei Wochen niemand mehr öffnet. Oder ein Miro-Board, das für alles Mögliche gebaut wurde, nur nicht für Event Storming.

Also habe ich eine eigene Plattform entwickelt, die exakt auf Event Storming zugeschnitten ist. Keine generische Whiteboard-App, sondern ein Werkzeug, das die Methode versteht.

So funktioniert es

Ich erstelle eine Session und schicke meinen Kunden einen Link. Kein Login, keine Installation, kein Account. Die Teilnehmer geben ihren Namen ein und sind sofort auf einer gemeinsamen digitalen Pinnwand.

Dort arbeiten wir in Echtzeit zusammen: Jeder sieht sofort, was die anderen kleben, verschieben oder markieren. Die Sticky Notes folgen dem Event Storming Farbsystem, Orange für Domain Events, Blau für Commands, Rot für Hotspots. Alles per Drag & Drop, alles live synchronisiert (über WebSockets).

Als Moderator steuere ich die Workshop-Phasen direkt im System. In der Phase „Chaotische Exploration“ sind nur orangene Stickies erlaubt, genau wie im echten Workshop. Erst wenn ich die nächste Phase freigebe, kommen die anderen Farben dazu. Das gibt dem digitalen Workshop dieselbe Struktur wie dem physischen.

So sieht die Session-Steuerung aus: Phasen wechseln, Share-Link teilen, Teilnehmer in Echtzeit sehen. Namen und Link sind aus Datenschutzgründen anonymisiert.

Warum kein Miro, kein Mural, kein FigJam?

Generische Whiteboard-Tools können vieles, aber sie bilden die Event Storming Methode nicht ab. Es gibt keine Phasensteuerung, kein Farbsystem mit fester Bedeutung, keine Moderation im Sinne des Workshops. Man muss sich selbst Templates basteln und darauf hoffen, dass sich alle daran halten.

Mein Portal macht das Gegenteil: Es schränkt bewusst ein, damit der Fokus bleibt. Genau wie beim physischen Workshop, wo der Moderator sagt: „Jetzt nur orangene Stickies.“ Das ist kein Feature-Mangel, das ist Designentscheidung, auf Code-Ebene.

Was meine Kunden davon haben

• Kein Tooling-Aufwand: Link öffnen, Name eingeben, loslegen. Kein Account, keine Lizenz, keine Einarbeitung.
• Remote-fähig ohne Kompromisse: Verteilte Teams oder Stakeholder an verschiedenen Standorten können genauso produktiv arbeiten wie vor Ort.
• Ergebnisse bleiben erhalten: Kein Abfotografieren von Whiteboards. Die Session bleibt bestehen, jederzeit wieder aufrufbar.
• Struktur statt Chaos: Die Phasensteuerung sorgt dafür, dass der Workshop einem klaren Ablauf folgt, auch digital.
• Direkte Zusammenarbeit in meinem System: Meine Kunden arbeiten nicht in irgendeinem Drittanbieter-Tool, sondern direkt bei mir. Das vereinfacht die Kommunikation und hält alles an einem Ort.

Ich habe das Portal gebaut, weil ich Event Storming ernst nehme und weil meine Kunden ein Werkzeug verdienen, das zur Methode passt. Nicht umgekehrt.

FAQ

Fazit

Event Storming ist für mich keine DDD-Übung. Es ist ein Kommunikationswerkzeug. Es bringt die richtigen Leute vor eine Wand (oder auf mein digitales Board) und macht sichtbar, was in Meetings, E-Mails und Pflichtenheften verloren geht: Widersprüche, implizites Wissen, fehlende Prozessschritte.

Ob du danach DDD, Clean Architecture oder eine klassische Dreischichtarchitektur baust, ist zweitrangig. Der Wert liegt im Verstehen, und das passiert an der Wand oder auf der digitalen Pinnwand, nicht im Code-Editor.

Wenn du ein Softwareprojekt planst und das Gefühl hast, dass Anforderungen und Realität auseinanderlaufen: Melde dich bei mir. Ich moderiere den Workshop, vor Ort oder remote über mein eigenes Event Storming Portal, und übersetze das Ergebnis in eine Architektur, die funktioniert.