Eventstorming
Ich habe einen Bericht im Java Magazin und ein YouTube Video gesehen und fand die Idee ganz interessant. An einem Happy Friday habe ich mir das mal genauer angeschaut.
Geschichte
2013 zum ersten mal unter diesem Namen aufgetaucht
kommt aus der Domain-Driven-Design Ecke
Konzept
"It is not the things that matter in early stages of design ... it is the things that happen" (Russ Miles)
Ziel des Event-Stormings ist die interaktive Schaffung eines gemeinsamen LĂśsungs-/Problemverständnisses. Man beginnt mit einer weiĂen Wand und Domain-Events, die in eine zeitliche Abfolge gebracht werden mĂźssen und mit Reaktionen angereichert werden. Am Ende hat man Konsens an einigen Punkten erreicht, wichtiges von unwichtigen unterschieden, Dissens gekennzeichnet ... eine gute Grundlage fĂźr die Kollaboration im weiteren Verlauf, um gemeinsam ein Outcome zu realisieren. Der Ansatz zwingt zwingt zur (kontroversen) Diskussion und Kollaboration in einer sehr frĂźhen Phase des Projekts. Man identifiziert eine unterschiedliche Erwartungshaltung, entdeckt unterschiedliches Verständnis und Sprache. Schafft man es trotz chaotischen Vorgehens die Diskussion kreativ, offensiv und zielorientiert zu einem weitestgehenden Konsens zu bringen, dann hat man einen sehr guten Grundstein gelegt und im besten Fall die Unternehmenskultur psoitiv weiterentwickelt. Ausgehend von dieser Athmosphäre werden Stakeholder auch in Zukunft nicht mehr Ăźbereinander und aneinander vorbei sprechen, sondern miteinander. So werden Probleme auch im weiteren Verlauf frĂźhzeitig adressiert und gemeinsam gelĂśst.
Die Formulierung von Anforderungen ist nicht Ziel eines Event-Stormings. Stattdessen will man (gruppenßbergreifend - Fachexperten, Architekten, Programmierer, Tester, Operations) Diskussionen fßhren, Silos werden aufgelÜst, gemeinsames Lernen durch Diskussion. Am Ende steht ein besseres und gemeinsames Verständnis der Domäne. Das hilft bei der Adressierung (Formulierung, Priorisierung) von Problemen und dem LÜsungsentwurf. Erst daraus ergeben sich dann die Anfoderungen.
Obwohl es sich um einen Ansatz aus dem Domain-Drive-Design handelt geht es hier im wesentlichen um die Prozesse und nicht um das darunterliegende Domänenmodell. Die Ereignisse (aka Domain Events) sind reale und nicht abstrakt - dadurch bleibt man fokussiert auf die Beschreibung realer Prozesse und ihrer Probleme. Das Domänenmodell kommt erst viel später und ist schon recht implementierungsnah (einige abstrakte Entities sind evtl. vorhanden, die bereits fßr einen bestimmten LÜsungsansatz entworfen wurden). Fokussiert man sich hingegen sofort auf die Modellierung des Domain-Modells, dann kann es leicht passieren, over-engineering zu betreiben, weil man Dinge in das Modell einmodelliert, die fßr die LÜsung nicht relevant sind.
Fßr diesen Ansatz braucht man nur Post-Its und viel Platz (Wand, Tisch, Boden). Ausgehend von Ereignissen identifiziert man die AuslÜser der Ereignisse (Commands - User, externes System, Zeit) kommt man zur Diskussion ßber die Reaktion auf dieses Ereignis. Auf diese Weise schafft man interaktiv ein dokumentiertes gemeinsames Verständnis, ohne sich in Technologie-Diskussionen zu verstricken. Die Domänenmodelierung entsteht praktisch von selbst.
Das Konzept Post-Its statt digitale Modellierungstools zu verwenden ist charmant, wenn man in der Gruppe modellieren will. Jeder kann sich beteiligen ... es gibt nicht DEN EINEN, der das Tool bedient. Stattdessen wird evtl. an ganz unterschiedlichen Events gleichzeitig gearbeitet, die Ergebnisse sind fĂźr jeden jederzeit vollständig sichtbar. AuĂerdem ist man in seiner Modellierungssprache in keinster Weise eingeschränkt ... es ist kein UML und kein BPMN und kein xyz, stattdessen entwickelt sich die Sprache gemeinsam weiter. BEDENKE: an der Diskussion sind häufig verschiedene Fachrichtungen beteiligt ... niemand soll durch die Festlegung auf eine bestimmte Notation ausgegrenzt werden - der Weg ist das Ziel. Die Verwendung einer weiĂen Fläche ermĂśglicht viele weitere einfache Modellierungsansätze:
Post-Its mit verschiedenen Farben und Formen
Linien um die Post-Its in verschiedenen Farben
beispielsweise, um Bounded Contexts oder Komponenten/Services zu visualisieren
ausgedruckte Icons, Bilder und SchriftzĂźge
Anordnung vollkommen frei - Umordnung jederzeit mit ein wenig Aufwand mĂśglich
Events sind meistens zeitlich gegliedert ... von links nach rechts
Formalismen von Tools (UML-Editoren zwingen zu korrekter Notation), Einschränkungen und Bedienungsprobleme dieser Tools stehen nicht im Weg. Selbst wenn das Tool von ein paar Teilnehmern exzellent beherrscht wird, dann sind die anderen auĂen vor.
Man kann es auf verschiedenen Levels durchfĂźhren
Big-Picture Event-Stormings
Design Event-Storming
Sprache
In der Farbgebung, Formen und Semantik der Zettel ist man vollkommen frei ... einige Standards haben sich aber schon etabliert. Die Sprache wird während der Diskussion weiterentwickelt. Findet man ein Konzept, das man mit den bisherigen Mitteln nicht ausdrßcken kann, dann wird ein neues Spracheelement definiert und in einer Legende festgehalten. Typischerweise sieht das dann so aus:
Domain Events: oranger Post-It
in Vergangenheitsform formuliert (z. B. "Taxi verpasst")
Command: blauer Post-It
Read Model: grĂźnes Post-It
hiermit sind Benutzereingaben gemeint
Attention/Hot-Spot (Risiko, Problem, Dissens): roter Post-It
Externes System: pink Post-It
DurchfĂźhrung
Events
In einer Stillen Anfangsphase schreiben die Beteiligten Domain Events auf die organgenen Zettel und kleben sie an die Wand - chronologisch (schon hier wird es zu einer Diskussion kommen). Dabei wird man im Zuge von Diskussionen die Events umgestalten
Doubletten entdecken
konkretisieren
umformulieren
voneinander abgrenzen
neue Events entdecken
Tips
"Focus on Behaviour, Not Data"
"Postpone Naming"
Bewertung
Vor der tatsächlichen Nutzung
Ich glaube, daà die Fokussierung auf Events - im Gegensatz zur Fokussierung auf die Substantive (wie bei DDD häufig empfohlen) - dazu fßhrt, daà die tatsächlichen Use-Cases der Domäne identifiziert und davon ausgehend ein sehr schlankes Domain-Modell entwirft. Geht man von den Substantiven aus, dann verleitet es dazu ein Modell zu entwerfen, das nicht zugeschnitten ist auf die Use-Cases, sondern zuviele Real-World-Eigenschaften aufweist, die in der Problem-Domäne gar nicht benÜtigt werden. Es entstehen also schlankere Modelle - weniger Komplexität.
Last updated
Was this helpful?