Einstieg in Event Storming

Es begann mit einem Job-Interview, bei dem die Bewerberin durch ihr tief gehendes Verständnis mehr als nur beeindruckte. Was für ein Glück, eine Kollegin kennenzulernen, die praktische Erfahrung mit DDD gemacht hatte und so viel über ihre letzten Tätigkeiten berichten konnte. Ein Angebot zu unterbreiten verstand sich da wie von selbst.Nach einigen Monaten ergab sich nach einem kurzen Plausch im Flur die Idee, gemeinsam mit einem weiteren Kollegen eine Gemeinschaft zu bilden, die sich dem Thema DDD nähert. In diesem Kontext sind wir auf die Methodik Event Storming gestoßen, über welche die dotnetpro bereits in [1] und [2] berichtete.Dieser Beitrag behandelt weder DDD noch Event Storming in voller Tiefe. Er ist ein Erfahrungsbericht über unseren Weg, der uns zu Event Storming geführt hat.

Der Start

Die ersten Meetings haben sich angefühlt wie in einer Findungsphase. Was wollen wir eigentlich genau machen? Wie organisieren wir uns?Man sollte denken, wenn einige Entwickler sich zusammentun, sollte alles wie von selbst laufen. Die Wahrheit sieht da doch ein bisschen anders aus. Wir haben uns gleich zu Beginn die Frage gestellt, was jeder Einzelne von uns mit einem solchen Vorhaben für sich und auch für unseren gemeinsamen Arbeitgeber erreichen möchte. Die folgende Liste enthält einen Auszug unserer gemeinschaftlichen Sammlung:

• Ich habe bereits an einem DDD-Projekt gearbeitet. Ich habe einige wichtige Lektionen gelernt, aber es gibt noch viel zu lernen. Ich hoffe, dies wird mir Gelegenheit geben, meine Kenntnisse zu vertiefen.
• Als ich DDD entdeckte und anfing, dies zu erlernen, machte es „Klick“ – ich erkannte, dass die Hauptursache für Probleme, mit denen ich in früheren Projekten konfrontiert war, mangelndes Domänenwissen und mangelnde Zusammenarbeit zwischen Entwicklungs- und Geschäftsleuten war.
• Ich vermisse in meiner täglichen Arbeit einige DDD-Methoden und ich glaube, dass sie uns hier in der Firma helfen können, uns zu verbessern.
• Wir setzen uns das Ziel, unsere Firma zu der „coolsten Softwareschmiede ever“ zu machen. Und dazu gehört es, dass
• wir kontinuierlich lernen und dies fester Bestandteil unserer Firmenkultur wird.
• Wie führe ich ein neues DDD-Projekt ein? Wie komme ich zu dem Domänenmodell?
• Kontinuierliches Lernen.
• Bessere Zusammenarbeit zwischen den Teams.
• Wir verbessern die Qualität unserer User Stories und der Testing-Szena­rios.
• Die Qualität des Quellcodes wird weiter optimiert.
• Wir haben eine Menge Spaß!

Unser finales Ziel war es, DDD so weit zu erlernen, dass wir in der Lage sind, das Wissen in unsere Firma zu transportieren. Nach dem einen oder anderen Termin – wir haben uns auf zwei pro Woche geeinigt – stellten wir fest, dass dieses Ziel zu ehrgeizig war. Die Theorie haben wir uns angeeignet. Für jeden Termin gab es „Hausaufgaben“, die es vorzustellen galt.

Accountability Partner – Fels in der Brandung

Die im Termin festgehaltenen Verbindlichkeiten jedes Einzelnen gegenüber den anderen sind wichtig. Nur so bringen die Termine Fortschritt.Die Autoren Gary Keller und Jay Papasan verdeutlichen in [3], dass sich durch einen solchen Accountability Partner, dem ein Schriftstück oder in unserem Fall ein Outlook-Termin präsentiert wird, in welchem das Ziel mit dem Lieferdatum festgehalten ist, die Wahrscheinlichkeit deutlich erhöht, dass dieses Ziel auch erreicht wird (vergleiche Bild 1).

An dieser Stelle möchte ich die Bedeutung einer solchen Partnerschaft unterstreichen. Nicht immer ist die Motivation durchgängig stark vorhanden; dann hilft es, wenn der Partner einen Schubs in die richtige Richtung gibt.Es gab auch bei uns die Situation, in der wir nicht mehr ganz sicher waren, ob wir alle noch die zu Beginn vereinbarten Ziele verfolgen. Die Investition von Energie und Freizeit in ein solches Vorhaben ist nicht zu unterschätzen. Äußere Faktoren spielen eine große Rolle und hätten auch fast zum Abbruch unseres Vorhabens geführt.Ein sehr offenes Gespräch, bei dem nochmals über die Ziele gesprochen wurde, hat uns jedoch weitermachen lassen. Zu diesem Zeitpunkt waren wir schon recht weit fortgeschritten, das heißt, wir hatten Event Storming bereits hinter uns gelassen und ein großer Teil war bereits technisch umgesetzt, sprich programmiert.

Die ersten Meetings

Zunächst haben wir uns mit den theoretischen Grundlagen beschäftigt, die wir unter anderem aus den Klassikern [4] und [5] erhielten. Entity, Aggregate, Bounded Context und dergleichen waren Inhalte unserer spannenden Diskussionen.Einer unserer ersten Gedanken war, eine technische Vorstellung von DDD durchzuführen. Sehr schnell war klar, dass dies allein mit dem theoretischen Wissen unbefriedigend ­wäre. Dass wir DDD selbst gemacht haben mussten, wenn wir darüber ernsthaft sprechen und uns auf Diskussionen mit den Kollegen einlassen wollten, war klar.

Erfahrungen sammeln im ersten DDD-Projekt

So haben wir uns damit beschäftigt, eine Idee für ein Projekt zu finden, das wir umsetzen wollten. Die Kollegin – sie hat bereits DDD-Projekte begleitet – schlug vor, ein Task-Management-System zu erstellen. Unser Projekt haben wir in unseren Google-Drive-Dokumenten wie folgt beschrieben:„Das Ziel des Projekts ist es, ein Beispiel zu haben, das gut genug ist, um mit DDD-Konzepten zu experimentieren und zu lernen, wie man eine Domäne modelliert.“Auf folgende Anwendungsfälle und Anforderungen haben wir uns geeinigt:

• Benutzer können ein Team erstellen und Teammitgliedern den Zugriff auf das Taskboard erlauben.
• Benutzer können die Einladung zum Zugriff auf das Taskboard des Teams annehmen.
• Der Benutzer sollte in der Lage sein, Sprints/Iterationen im Iteration Backlog zu definieren.
• Der Benutzer sollte einen Überblick über die ihm zugewiesenen Aufgaben haben.
• Der Benutzer sollte in der Lage sein, Aufgaben in verschiedenen Zuständen zu verfolgen.
• Der Benutzer sollte in der Lage sein, Aufgabenzuweisungen zu ändern.

Zu den Aufgaben/Tasks wurde Folgendes festgehalten:

• Der Benutzer kann einen Task erstellen.
• Der Task muss eine Beschreibung enthalten.
• Der Task muss Akzeptanzkriterien enthalten.
• Der Task muss einen Arbeitsvoranschlag (in Stunden) enthalten.
• Der Task sollte protokollierte Arbeit (in Stunden) enthalten.
• Der Task kann Kommentare enthalten.
• Der Benutzer kann den Task einem anderen Benutzer oder sich selbst zuweisen.
• Der „Assignee“ kann mit der Arbeit an einem Task beginnen.
• Der „Assignee“ kann einen Task abschließen.

Der Einstieg ins Event Storming

Wir waren einen wichtigen Schritt weitergekommen, weil wir wussten, was wir grundsätzlich wollten. Doch wie sollte es weitergehen? Wie sollten wir richtig DDD aus unseren Anforderungen machen? Sollten wir einfach mal loslegen und Entitäten in C#-Klassen abbilden, so wie wir es für richtig hielten?Die Kollegin hat immer wieder den Namen Alberto Brandolini [6] im Zusammenhang mit Event Storming genannt. Ihr war auch das Buch [7] von Alexey Zimarev vertraut, der in seinem Werk die Methode Event Storming vorstellt. Sein drittes Kapitel dreht sich um diese Methode, und so haben wir damit begonnen, das zu tun, was auch er tat: Wir haben uns auf die Suche nach einer digitalen Leinwand gemacht und sind schlussendlich wie auch Alexey Zimarev bei dem Online-Tool Miro [8] gelandet. Die Vorlagen bei Miro bieten tolle Shapes an, die den bei Event Storming benötigten Notizzetteln sehr nahekommen.Die Urlaubszeit hat das gemeinsame Vorhaben pausieren lassen. Meine Neugier war allerdings geweckt, und so habe ich einen Event-Storming-Alleingang während des Urlaubs unternommen. Allein ist es jedoch ein bisschen zäh.Auch wenn die Erläuterungen in [7] gut sind, ist zu Beginn die Unsicherheit der ständige Begleiter. Da die Farben der Zettel verschiedene Bedeutungen haben, habe ich mir diese zunächst als „Spickzettel“ festgehalten (Bild 2).

Zimarev empfiehlt, für den Einstieg [7] einfach mal ein erstes Domänen-Ereignis auf einen Zettel zu schreiben und hinzukleben, immer in der Formulierung, dass das Ereignis bereits stattgefunden hat. Für mich habe ich das Ereignis „Task created“ gefunden.Da das Board eine Zeitleiste darstellt, die von links nach rechts zu lesen ist, habe ich weitere Ereignisse ergänzt. Das Resultat zeigt Bild 3.

Entsprechend Zimarev habe ich mein Board um Kommandos ergänzt. Die in [7] vorhandene Reihenfolge zu befolgen hat mir geholfen. In Bild 4 sind die ergänzten Kommandos zu sehen. Es mag hier vermutlich einen recht simplen Eindruck machen, einfach ein paar Zettel zu kleben, aber mir hätte ein Gesprächspartner zu diesem Zeitpunkt sehr geholfen.

Noch hatte ich Urlaub und ich wollte die Zeit nutzen, um voranzukommen. Als Nächstes ging es um die Berechtigungen. Welche Rolle darf was tun? Die nächsten Zettel, diesmal in Gelb, haben ihren Weg auf das Board gefunden (Bild 5).

Auch wenn dieser Alleingang, wie schon erwähnt, nicht ganz einfach war, hat es Spaß gemacht, und für mich war klar, dass diese Methodik hilft, die Anforderungen in einem größeren Zusammenhang zu betrachten und zu verstehen.Nachdem das initiale Ereignis „geklebt“ wurde, ergeben sich Fragen wie zum Beispiel, wie dieses auslöst wird? Oder woher zum Beispiel die User kommen? Müssen diese manuell angelegt werden, oder sollten diese beispielsweise aus dem Active Directory importiert werden können?

Die gebündelte Kraft als Team

Ein Sprichwort sagt: „Möchtest du schnell sein, gehe allein. Möchtest du weit kommen, gehe in der Gruppe.“ Ich glaube nicht, dass ich bei meinem ersten Versuch besonders schnell war, aber wie bereits erwähnt: Es hat mich weitergebracht.Mein Ergebnis habe ich nach dem Urlaub meinen Partnern vorgestellt. Fast hatte ich den Eindruck, dass man mir ein bisschen böse war, diesen Schritt allein gemacht zu haben – es war doch unser gemeinsames Projekt.Also haben wir Event Storming nochmals gemeinsam von Anfang an vollzogen. Ein neues, leeres Board wurde angelegt und wir haben eifrig „geklebt“ und diskutiert. Die Reihenfolge, das heißt zunächst die Domänen-Ereignisse zu bestimmen, dann die Kommandos, und sich danach über die Berechtigungen Gedanken zu machen, haben wir beibehalten, was auch gut funktioniert hat. Unser Resultat zeigt Bild 6.

Die Methodik Event Storming hat uns gute Dienste erwiesen und führte zu spannenden Diskussionen. An dieser Stelle schließe ich meinen Erfahrungsbericht, die technische Umsetzung ist von dieser Publikation ausgeschlossen.

Fazit

Was kann ich jetzt über Event Storming sagen? Auch wenn ich es bisher „nur“ im Rahmen eines Lernprojekts angewendet habe, stufe ich es als eine sehr hilfreiche Methodik ein, wenn es darum geht, Projektbeteiligte aus den verschiedenen Fachbereichen (Entwicklung, Vertrieb, Management, Marketing) an einen Tisch zu bekommen, eine gemeinsame Sprache zu sprechen und sich der Aufgabenstellung aus den verschiedenen Perspektiven zu nähern.Als sehr wertvoll hat sich die Accountability-Partnerschaft mit meinen Kollegen erwiesen. Wenn man, so wie es bei uns der Fall war, das erworbene Wissen transportieren möchte, sollte dies möglichst schnell erfolgen. Inzwischen sind wir in der technischen Umsetzung weit fortgeschritten, und erst jetzt bieten wir an, Event Storming gemeinsam mit unseren Kollegen zu erkunden. Hätten wir dies bereits früher umgesetzt, so hätte dies sicherlich auch einen zusätzlichen Motivationsschub gegeben und wir hätten weitere Aspekte aus den Diskussionen gelernt.

Fussnoten

1. Jan Fellien, Marco Heimeshoff, Im Auge des Tornados, dotnetpro 7/2017, Seite 16 ff., http://www.dotnetpro.de/A1707EventStorming
2. Susanna Roden, Der nächste Urlaub kommt bestimmt, dotnetpro 11/2017, Seite 63 ff., http://www.dotnetpro.de/A1711EventStorm
3. Gary Keller, Jay Papasan, The ONE Thing: The Surprisingly Simple Truth Behind Extraordinary Results, Bard Press, 2013, ISBN 978-1-885167-77-4,
4. Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, Addison-Wesley, 2004, ISBN 978-0-3211-2521-7,
5. Vaughn Vernon, Implementing Domain-Driven Design, Addison-Wesley, 2013, ISBN 978-0-321-83457-7,
6. EventStorming, http://www.eventstorming.com
7. Alexey Zimarev, Hands-On Domain-Driven Design with .NET Core, Packt Publishing, 2019, ISBN 978-1-78883-409-4,
8. Online collaborative whiteboard platform miro, http://www.miro.com