Suche
Domänen im Rückwärtsgang erforschen

Domain-driven Design in Aktion: Mehr Dynamik mit Event Storming

Matthias Bohlen
shutterstock_224837770

©Shutterstock / Olaf Naami

Traditionelle Anforderungsworkshops ohne Beteiligung der Entwicklung erfüllen den heutigen Time-to-Market-Anspruch nicht mehr. Mit dem vor einigen Jahren eingeführten User Story Mapping wurde das immerhin schon einmal besser. Was ist aber, wenn das Grundverständnis der Fachdomäne im Team noch nicht hergestellt ist, sodass das Story-Schreiben schwerfällt? Hier kann Event Storming helfen, eine Workshopmethode aus der Domain-driven-Design-Familie. Fachexperten und IT-Leute verbrauchen dabei enorm viele Post-its, um ein gemeinsames Verständnis einer Fachdomäne zu bekommen.

Domain-driven Design (DDD), das Eric Evans schon 2004 definiert hat [1], feiert fröhlich Auferstehung. Angefeuert durch aktuelle Themen wie Microservices-Architekturen und DevOps-Kultur. Es geht darum, gemeinsam mit Fachexperten eine Domäne mittels DDD zu erforschen, also den Kontext des zu lösenden Problems tiefgreifend zu verstehen, bevor man mit scharfen Messern herangeht und Microservices schneidet. Das sollte eigentlich selbstverständlich sein. Was könnte andernfalls passieren, wenn man dies nicht tut?

  • Wir lösen ein Problem mit Software, das wir besser organisatorisch gelöst hätten und produzieren so vermeidbare Kosten.
  • Wir schneiden Microservices und errichten harte Remote-Call-Grenzen dazwischen und handeln uns plötzlich große Refactoring-Aufwände ein, wenn endlich das Domänenverständnis einsetzt.
  • Wir glauben zu verstehen, was gefordert ist, entwickeln los, und merken zu spät, dass wir zu wenig wussten und deshalb teure Iterationsschleifen ziehen müssen.
  • Wir ignorieren den Beitrag mancher Stakeholder, weil es uns anfänglich zu viele waren und merken später, dass diese Stakeholder ein völlig neues Licht auf die benötigten Funktionen werfen.

Ich bin überzeugt von Lean und Kanban und deshalb kein Fan davon, viel auf Vorrat zu erheben und zu entwerfen. Doch dass Iterationen Geld kosten, ist auch klar. Wie könnten wir also die Sicherheit gewinnen, tatsächlich das richtige Problem zu lösen? Einen besseren Startpunkt zum Iterieren finden und mehr Stakeholder einbeziehen, ohne verrückt zu werden? Außerdem wollen wir die Domänen im Team früh und gemeinsam besser verstehen. Und Risiken, seltsam gestaltete Geschäftsprozesse und mögliche Know-how-Lücken, frühzeitig erkennen und einbeziehen anstatt davon überrascht zu werden. Dafür gibt es eine Methode, die gute Ergebnisse liefert und auch noch Spaß macht: Event Storming.

Lesen Sie auch: Einführung in die Konzepte von Domain-driven Design

Was ist Event Storming?

Event Storming ist eine Methode, um in interaktiven Workshops mit Fachexperten und IT-Leuten gemeinsam eine Domäne so weit zu erforschen und zu verstehen, dass man anschließend locker mit dem Entwurf der ersten Subsysteme loslegen kann. Man sortiert die Unordnung und die seltsamen Dinge aus, bevor Software entwickelt und zu viel Geld ausgegeben wird. Dadurch gewinnt man einen Vorsprung für das spätere Iterieren.

Der italienische Consultant Alberto Brandolini (auch bekannt als @ziobrando, Onkel Brando) hat Event Storming ausführlich beschrieben. Es ist eine Art Brainstorming, bei dem eine Gruppe gemeinsam die wichtigen fachlichen Ereignisse (Businessevents) findet, die im Geschäftsprozess auftreten. Aus diesen Ereignissen gewinnen die Mitglieder der Gruppe Anknüpfungspunkte, aus denen sie alles andere ableiten, wie Geschäftsprozesse, Daten oder Nutzeroberflächen.

Ein fachliches Ereignis ist eine Tatsache, die während des Geschäftsprozesses passiert ist und die für den Start neuer Prozesse sorgen kann. Es ist ein Faktum, also eine kurze Aussage, die bewusst in der Vergangenheit formuliert ist. Beispiele für fachliche Ereignisse aus der Domäne Versandhandel sind: Bestellung eingegangen, Ware ausgeliefert, Zahlung eingegangen oder Mindestbestand im Lager unterschritten.

Event Storming beginnt eben nicht vorne bei den Usern und deren Bedürfnissen und fragt, was die User brauchen, wo das System unterstützen kann und was am Ende dabei herauskommen soll. Event Storming beginnt ganz am Schluss, bei den Dingen, die schon längst passiert sind – also bei Zahlung eingegangen – und fragt, wie es dazu kommen konnte. Es muss eine Ursache für die Zahlung gegeben haben. Es muss also jemanden gegeben haben, der so zufrieden mit etwas war, dass er dafür bezahlt hat. Im Handel ist das der Kunde, der die Ware bekommen hat. Wie konnte das geschehen?

Die Ware muss wohl ausgeliefert worden sein – nächstes Event gefunden: Ware ausgeliefert. Wie konnte es dazu kommen? Jemand, in dem Fall der Arbeiter im Warenausgang des Lagers, muss entschieden haben, die Ware zu verschicken und der Lastwagenfahrer muss sie mitgenommen und zum Kunden gebracht haben. Welche Informationen hat der Lagerarbeiter dafür gebraucht? Woher wusste er, was und wieviel er ausliefern musste? Allgemein gesagt: Welche Informationen musste das neue Handelssystem ihm geben, damit er die Entscheidung, die Ware tatsächlich zu verschicken, fällen konnte? So kommen wir endlich beim User an und bei den Daten, die ihm das System an der Oberfläche zu präsentieren hat, damit der User Aktionen auslösen kann.

Wir könnten mit dem Domänenwissen, das wir jetzt haben, zu anderen Methoden wechseln, z. B. eine traditionelle User Story schreiben, die zeigt, was der Lagerarbeiter macht. Oder wir könnten erst einmal sagen: Lasst uns den Lagerarbeiter besuchen und filmen, was er bisher macht  – Stichwort User-centered Design (UCD).

Event Storming arbeitet in einer Art Rückwärtsgang, den das Team mit den Fachexperten einlegt. Das fühlt sich anfangs wirklich seltsam an, führt aber zu gutem Domänenverständnis und macht unglaublich viel Spaß.

Wie läuft ein Event-Storming-Workshop?

Die Zutaten für einen Event-Storming-Workshop sind denkbar einfach:

  • Lade die richtigen Leute zum Workshop ein, also die beste Mischung aus Stakeholdern und Problemlösern sowie einen Moderator.
  • Gib ihnen unbegrenzten Platz zum Modellieren an der Wand.
  • Bringe sie dazu, einen geschäftlichen Fluss aus fachlichen Ereignissen entlang einer Zeitlinie zu modellieren.
  • Markiere dort kritische Bereiche, seien es Risiken, Schlüsselfeatures oder Möglichkeiten zur Verbesserung.

Entscheidend für die erfolgreiche Ausführung dieses Rezepts ist die richtige Vorbereitung.

Den Raum vorbereiten

Als Moderator bereitet man den Raum für einen erfolgreichen Workshop vor. Entfernen Sie zunächst alle Stühle – der Workshop findet im Stehen und Laufen statt. Sitzen animiert zum teilnahmslosen Zuhören. Das wollen Sie in so einem Workshop nicht. Räumen Sie die Tische beiseite, sodass eine große freie Fläche vor einer Wand entsteht. Wenn das nicht geht, mieten Sie einen externen Raum oder nehmen Sie einen langen Korridor anstatt eines Raums. An eine Seite der Wand stellen Sie einen kleinen Tisch zum Schreiben, mehr nicht. Befestigen Sie an der Wand eine wirklich lange Rolle Packpapier – am besten mehr als zehn Meter davon. Auf dieses Packpapier kleben die Leute später ihre Post-its. Stellen Sie neben die Wand ein Flipchart, auf dem Sie eine immer sichtbare Legende zeichnen, die den Teilnehmern des Workshops als Anhaltspunkt dient.

Abb. 1: Als ich das Event Storming als Workshop auf einer Konferenz durchführte, merkten alle Teilnehmer, wie hinderlich Tische und Stühle sein können

Abb. 1: Als ich das Event Storming als Workshop auf einer Konferenz durchführte, merkten alle Teilnehmer, wie hinderlich Tische und Stühle sein können

Der Start

Geben Sie den Leuten nun orange Post-its sowie einen mitteldicken schwarzen Filzstift pro Person und erklären Sie: „Jedes orange Post-it steht für ein fachliches Event. Ein fachliches Event ist eine fachlich relevante Tatsache, die im Geschäftsablauf passiert ist. Das Verb auf dem Post-it muss also in der Vergangenheit stehen.“ Notieren Sie das auf der Legende auf dem Flipchart (Abb. 2).

Am Anfang traut sich häufig niemand, das erste Post-it aufzuhängen. Warten Sie in Ruhe ab. Feiern Sie den ersten Freiwilligen, der es tatsächlich macht. Wenn sich nichts tut und sich keiner traut, schreiben Sie selbst ein Eventticket, das bewusst falsch ist. Bitten Sie die Gruppe darum, es neu zu schreiben und zu verbessern. Niemand möchte als blöd dastehen, tun Sie so, als seien Sie es, der blöd ist, und lassen Sie die anderen gut dastehen. Alle anderen machen dann mit und kommen in den Flow.

Abb. 2: Die Workshopbegleitende Legende

Abb. 2: Die Workshopbegleitende Legende

Die erste Eventrunde

In der ersten viertel bis halben Stunde entstehen sehr viele Post-its für Events. Bitten Sie die Leute, die Events in der zeitlichen Reihenfolge ihres Auftretens aufzuhängen (Abb. 3). Das wird die Leute automatisch dazu bringen, Ursache-Wirkung-Beziehungen zwischen den Events zu diskutieren und Lücken zu erkennen: „Moment mal, hier zwischen ‚Bestellung eingegangen‘ und ‚Ware ausgeliefert‘ muss noch ‚Zahlung eingegangen‘, sonst kriegen wir ja gar kein Geld!“ Die Wand wird sich füllen, der Lärm im Raum wird zunehmen, weil Diskussionen über die Events, deren Bedeutung, Zusammenhang und zeitliche Reihenfolge entstehen. Diese Diskussionen sind das eigentlich Wertvolle. Sie führen zu Lernerfahrung und Wissen.

Abb. 3: Events zeitlich geordnet aufhängen

Abb. 3: Events zeitlich geordnet aufhängen

Verfeinerungsrunden

Gehen Sie mit den Teilnehmern die aufgehängten Eventzettel durch. Bitten Sie die Teilnehmer, zu erklären, was jedes Event bedeutet. Prüfen Sie auf syntaktische Korrektheit. Wenn ich so etwas moderiere, hänge ich alle Events, die kein Verb in der Vergangenheit enthalten, in der ersten Runde um 45 Grad schräg und spreche mit den Teilnehmern in der zweiten Runde darüber, wie man sie verbessern kann. Diskutieren Sie auch noch einmal, ob die Events zeitlich in der richtigen Reihenfolge hängen. Vereinheitlichen Sie auftretende Synonyme (verschiedene Begriffe für dasselbe) und schärfen Sie Unterschiede, falls mit demselben Begriff unterschiedliche Dinge bezeichnet wurden. Sorgen Sie außerdem dafür, dass sich alle am Ende der ersten Verfeinerungsrunde mit der Begriffswelt halbwegs wohlfühlen, damit die weiteren Runden danach in gemeinsamer Sprache schnell über die Bühne gehen können.

Ursachen verfolgen

Steigen Sie jetzt in die Ursachenforschung ein. Woher kommen die fachlichen Events? Da gibt es vier Hauptursachen: Useraktionen, externe Systeme, Zeit (z. B. Termin verstrichen) und andere Domänenevents (durch automatische Reaktionen). Fragen Sie nach den Auslösern der Events. Bitten Sie die Teilnehmer, an den Events entlang zu gehen und Post-it-Tickets (Tabelle 1) für die Auslöser und weitere Elemente hinzuzufügen, gemäß der Legende auf dem Flipchart (Abb. 2):

Bedeutung Ticketgröße Ticketfarbe
User klein gelb
Command klein blau
Aggregat groß gelb
External System groß rosa
Read Model klein grün
User Interface groß weiß
Policy klein lila

Tabelle 1: Ticketfarben für die Domänenmodellelemente

Erklären Sie die anderen Elemente des Modells, sobald sie auftreten. Ein Command ist beispielsweise ein Kommandoobjekt mit weiteren Daten als Parameter. Es ist am Ende das Ergebnis einer Benutzerentscheidung und wirkt auf Aggregate oder externe Systeme ein und sagt ihnen, was sie machen sollen. Ein Aggregat ist eine Zusammenfassung von Entitäten und Wertobjekten, die immer gemeinsam als Einheit konsistent sein müssen und können. Ein Read Model ist eine Datenzusammenstellung ohne spezielles Verhalten, die darauf zugeschnitten ist, in einem bestimmten Use Case angezeigt zu werden. Und eine Policy ist ein automatisch ausgelöster Ablauf („Immer wenn X, dann machen wir Y“).

Risiken markieren

Ich reserviere mir immer eine unbenutzte Kombination von Ticketgröße und Ticketfarbe für die so genannten WTF-Tickets, z. B. klein und pink. WTF ist eine Abkürzung für einen wüsten amerikanischen Ausdruck, den man vielleicht noch vornehm mit „Was zur Hölle“ übersetzen könnte. Wenn beim Durchgehen der Post-its an der Wand Probleme oder seltsame unlogische Abläufe sichtbar werden oder unklare widersprüchliche Begriffe auftauchen, schreibt man dafür ein „Was zur Hölle“-Ticket. Zum Beispiel: „Wann zur Hölle wird denn nun genau die Freigabe für Aufträge mit mehr als 100 000 Euro erteilt?“ und „Wer zur Hölle macht diese Freigabe?“ oder „Warum zur Hölle dauert dieser Prozess mehr als zehn Tage?“. Auf dem Ticket würde natürlich nur die Kurzform stehen, also „Freigabe > 100 000“ oder „Warum > zehn Tage?“. WTF-Tickets markieren aufgedeckte und für alle transparent gemachte Risiken für ein eventuell nachfolgendes Entwicklungsprojekt.

Umsortieren und Ergebnis

Jetzt ist der Zeitpunkt, die Post-its von der Zeitlinie wegzunehmen und sie um die gefundenen Aggregate herum zu gruppieren (Abb. 4). Dadurch werden diese neuen Zusammenhänge klar:

  • Welche User lösen welche Commands aus?
  • Welche Commands wirken auf welche Aggregate oder externe Systeme und lösen welche Veränderungen aus?
  • Welche Aggregate oder externe Systeme lösen während der Verarbeitung von Commands welche Events aus?
  • Welche Events bringen welche Policies zum Ablauf?
  • Aus welchen Events entstehen welche Read Models für welche Use Cases?
  • Welche Policies rufen wiederum welche neuen Commands auf?
Abb. 4: Umsortieren rund um Aggregate

Abb. 4: Umsortieren rund um Aggregate

Wenn ich solche Workshops moderiere, merke ich, dass nicht alle Teilnehmer des Workshops bei jedem Element des entstehenden Modells mitreden möchten. Bei Events machen noch alle mit, bei Policies und Commands vielleicht noch die meisten, bei UIs und Read Models ebenfalls noch einige, doch bei Aggregaten reden meist nur die Entwickler mit. Manchmal ist es gut, wenn Sie Event-Storming-Workshops deshalb zweimal durchführen: Einmal mit allen, als Überblick, dann noch einmal mit denen, die tiefer in die Details des Designs einsteigen möchten oder müssen.

Als sichtbare Ergebnisse der Event-Storming-Workshops bekommen Sie Modelle aus Post-its. Diese Modelle zeigen, wie die Abläufe sind oder sein sollen, welche User, welche Systeme, welche Daten und welche Prozesse daran teilnehmen. Sie bekommen einen richtig guten Überblick über das, was in einer Fachdomäne passiert.

Wie weiter?

Event Storming bildet eine hervorragende Grundlage für ein ausgearbeitetes Domänenmodell. Aus den Post-its, die um Aggregate herum angeordnet sind, erkennen Sie oft Bereiche, in denen Begriffe eine ganz bestimmte Bedeutung haben. Diese Bereiche können zu Bounded Contexts in Ihrem Domänenmodell werden, beispielsweise Disposition, Einkauf, Lager, Verkauf oder Rechnungsprüfung. Diese Bereiche können Sie Ihren Entwicklungsteams geben, die darin weiter entwerfen und realisieren.

Die Aggregate und Policies sind Grundlage für den Entwurf von (Micro-)Services, die jeweils eine bestimmte, dedizierte Aufgabe und Verantwortlichkeit bekommen. Ihr System bekommt damit eine gute, wartbare Struktur, und die Menge der Refactorings auf diesen Microservices wird geringer sein als ohne das im Event Storming erworbene Wissen.

Event Storming bildet auch den Andockpunkt für andere detailliertere Methoden. Sie können mit User Story Writing den Weg beschreiben, den Ihr Entwicklungsvorhaben nehmen soll. Immer wenn Sie einen User und ein Command sehen, das von diesem User ausgelöst wird, können Sie eine User Story schreiben, die exakt dieses Command als Output hat. Diese User Story können Sie in das Backlog und in die Release- und Iterationsplanung Ihres Vorhabens aufnehmen.

Lesen Sie auch: Domain-driven Design im Experten-Check: Warum ist DDD heute relevanter denn je?

Read Models (die grünen Post-its) beschreiben die Informationen, die der User braucht, um eine bestimmte Entscheidung zu fällen. User Interfaces (die weißen Post-its) sind Platzhalter für die benötigte Präsentation dieser Informationen. Beides zusammen bildet einen Andockpunkt für systematische User Experience und User-centered-Design-Arbeit.

Fazit

Beim Event Storming entsteht auch Unsichtbares: Durch die Zusammenarbeit der Leute werden Grenzen zwischen Know-how-Silos überwunden und viele Aha-Erlebnisse ausgelöst. Auf die während des Workshops geführten Diskussionen beziehen sich die Leute auch später noch ganz oft. Diese Art Workshop schweißt Fachexperten und IT-Leute stärker zusammen, die sich sonst ja immer ein wenig fremd bleiben. Beide gemeinsam haben ein Ergebnis erzielt, mit dem sie weiterarbeiten und auf das sie stolz sein können. Event-Storming-Workshops halte ich deshalb sehr gerne und empfehle Ihnen, es im eigenen Unternehmen auch einmal mit diesem so seltsam effektiven Rückwärtsvorgehen zu versuchen.

Geschrieben von
Matthias Bohlen
Matthias Bohlen
Matthias Bohlen arbeitet als Experte für effektive Produktentwicklung. Teams engagieren ihn als Coach in vielen Projekten, um Prozesse, Architektur und Organisation für sich selbst zu finden und aufzustellen. Matthias Bohlen hilft aktuell auch Teams, die gerade die Startup-Phase verlassen und zu einer erfolgreichen Company skalieren. Er hat für Sie zu dem Thema weiteres Material zusammengestellt, das Sie unter http://scaletonextlevel.com finden können.
Kommentare

Hinterlasse eine Antwort

Deine E-Mail-Adresse wird nicht veröffentlicht.