mit EventStorming und Example Mapping Dieser Artikel wurde im leanpub-Buch veröffentlicht: Domain-Driven Design: Die ersten 15 Jahre
Einführung
Die Leute fragen oft nach konkreteren Anleitungen, wie man Modelle erforscht, insbesondere in einem agilen oder schlanken Umfeld. Der Model Exploration Whirlpool ist Eric Evans Versuch, solche Ratschläge schriftlich festzuhalten. Es handelt sich nicht um einen Entwicklungsprozess, sondern um einen Prozess, der in die meisten Entwicklungsprozesse passt. Das zentrale Thema, um das sich der Prozess dreht, ist, das Modell immer wieder zu hinterfragen. Während der Prozess selbst für die meisten geradlinig und leicht zu verstehen ist, gibt es nicht viele konkrete Beispiele dafür, wie man einen solchen Modellexplorations-Wirbel durchführt. Die meisten Menschen, die mit der Anwendung von Domain-driven Design (DDD) beginnen, sind auf der Suche nach solchen praktischen Beispielen. In diesem Artikel erzähle ich Ihnen, wie ich den Modell-Explorations-Wirbel durch die Kombination von EventStorming, einer Technik aus der DDD-Community, und Example Mapping, einer Technik aus der Behaviour Driven Development (BDD)-Community, eingesetzt habe.
© domainlanguage.com
Ernten und dokumentieren
Wir beginnen die Modellexploration mit dem Erfassen und Dokumentieren des aktuellen Zustands. Wenn Sie keinen Ist-Zustand haben und auf die grüne Wiese gehen, keine Sorge, wir kommen zu diesem Teil. Die primären Ziele sind das Sammeln von Referenzszenarien, das Erfassen von Teilen des Modells und das Verlassen der meisten Ideen. Der Ausgangspunkt für diese Phase kann eine der folgenden sein: eine Einschränkung, die sich aus einem EventStorming des großen Ganzen ergibt, ein neues Projekt oder einfach eine User Story im Backlog. Solange es eine Geschichte zu erzählen gibt, ist dies ein guter Ausgangspunkt.
Eines meiner Lieblingstools ist EventStorming, ein flexibles Tool für die kollaborative Erforschung komplexer Geschäftsbereiche. In nur wenigen Stunden können Sie eine Menge Wissen sammeln und dokumentieren. Für den Erfolg dieser Phase ist es jedoch wichtig zu wissen, wer die richtigen Personen sind, die Sie einladen sollten. Das sind die Leute, die den Bereich kennen, die Fachexperten. Wir wollen so umfassend wie möglich sein, aber es gibt auch Ausnahmen. Es ist wichtig, dass wir einen sicheren Ort schaffen, an dem das Wissen frei fließen kann. Ein großartiger Moderator kann Wunder bewirken, aber es gibt auch Grenzen. Menschen, die giftig sind, sind für einen produktiven Workshop tödlich, so dass wir vielleicht beschließen sollten, eine solche Person auszuschließen. Aber diese Person kann eine Menge Fachwissen haben, das für diese Phase wichtig ist. In dieser Phase ist es vielleicht ratsam, vor einem solchen Workshop mit dieser Person zu sprechen und zu sehen, ob wir einige Informationen herausbekommen können, oder noch besser, aber schwieriger, das toxische Verhalten dieser Person zu ändern, damit sie am Workshop teilnehmen kann.
Der Workshop
Wichtig ist dabei, dass Sie genügend Platz zum Modellieren finden, am besten unendlich viel Platz (wenn überhaupt!). Ich suche nach Räumen mit einer mindestens 8 Meter langen Wand, auf die ich eine Papierrolle legen kann, und wir brauchen definitiv ein Whiteboard. Jetzt können wir damit beginnen, den aktuellen Zustand zu erfassen, indem wir einen Prozess-EventStorm durchführen. Wir geben den Teilnehmern orangefarbene Klebezettel und einen Marker. Wir bitten sie, Domänenereignisse aufzuschreiben, ein Muster, das später im Referenzbuch von Eric Evans hinzugefügt wurde. Ein Domänenereignis ist, kurz gesagt, ein geschäftsrelevantes Ereignis, das in der Domäne stattgefunden hat. Für den Prozess EventStorming wollen wir die Domänenereignisse des aktuellen Zustands erfassen und sie in zeitlicher Reihenfolge auf das weiße Papier bringen. Es wird viel Chaos herrschen. Sorgen Sie also für ein gewisses Erwartungsmanagement und erklären Sie, dass wir das Ganze schließlich strukturieren werden.
Eine Geschichte erzählen
Wenn jeder seine Domänenereignisse aufgeschrieben hat, ist es an der Zeit, eine Geschichte zu erzählen. Lassen Sie die Teilnehmer jetzt die Zeitachse durchsetzen, indem sie die Geschichte konsistent machen. Entfernen Sie doppelte Ereignisse, aber stellen Sie sicher, dass es sich tatsächlich um Duplikate handelt. Oft wird angenommen, dass ein Domänenereignis dasselbe ist, was aber nicht der Fall ist. Seien Sie konkret und spezifisch. Rechnen Sie damit, dass es zu diesem Zeitpunkt unterschiedliche Meinungen über die Expertise gibt. Markieren Sie diese mit einem leuchtend rosafarbenen Klebepunkt, einem so genannten Hotspot, der schon von weitem sichtbar ist.
Machen Sie das Selbstverständliche explizit
Der Kern von visuellen Meetings wie EventStorming ist, dass wir nur explizite und sichtbare Dinge besprechen. Es gibt einfach so viel Wissen, das wir in Domänenereignissen und Hotspots erfassen können; wir können mehr Arten von Wissen mit anderen Farben erfassen. Die Standardfarben von EventStorming sind (aber machen Sie Ihre Legende mit den Farben, die Sie zur Verfügung haben):
- Blau: Aktion/Befehl
- Langes Rosa: (externes) System
- Langer Flieder: Politik/Eventual Business Constraint
- Grün: Informationen
Für weitere Informationen über Eventstorming lesen Sie das Buch von Alberto Brandolini
Der grundsätzliche Ablauf wird so aussehen, aber der entscheidende Punkt ist, die Kommunikation explizit zu machen. Wenn sie für jeden im Raum explizit ist, reicht das aus. Wenn wir es nicht wissen, versuchen Sie, diesem Ablauf zu folgen. Denken Sie daran, das Implizite explizit zu machen. Diskussionen, die nicht auf der Papierrolle stattfinden, müssen explizit gemacht werden. Manchmal ist es schwierig, dies mit ein paar Klebezetteln auszudrücken. Deshalb müssen wir ein Whiteboard zur Hand haben, auf dem wir Skizzen und Zeichnungen anfertigen oder Teile des Modells aufschreiben können.
Vorurteil blinder Fleck
Jetzt, wo wir denken, dass die Geschichte vollständig ist, wollen wir das Example Mapping einführen. In den meisten Fällen werden die Leute jetzt glauben, dass es Verschwendung ist, ein weiteres Tool hinzuzuziehen. Wir haben unsere Geschichte richtig visualisiert; wir haben die ganze Geschichte? Das Problem ist, dass jeder Mensch einer kognitiven Voreingenommenheit unterliegt, vor allem, wenn wir mit Informationen überflutet werden. Wir bemerken Dinge, die bereits im Gedächtnis verankert sind oder oft wiederholt werden. Dies wird als Kontexteffekt und Aufmerksamkeitsverzerrung bezeichnet. Wir werden auch von Details angezogen, die unsere eigenen Überzeugungen bestätigen. Dies wird als Beobachtereffekt und Bestätigungsfehler bezeichnet. Vor allem der blinde Fleck, d.h. die Tatsache, dass wir Fehler bei anderen leichter bemerken als bei uns selbst, ist bei der Erkundung des Bereichs gefährlich. Um diese Voreingenommenheit zu bekämpfen, müssen wir andere Blickwinkel, andere Werkzeuge verwenden.
Die Zuordnung von Beispielen hilft uns hier, weil sie sich mehr auf konkrete Beispiele konzentriert. Machen Sie Platz auf einem anderen Teil der Modellfläche, entweder neben Ihrem EventStorm oder auf einer separaten Papierrolle. Beginnen Sie mit dem Storming, indem Sie Beispiele auf (in der Regel grüne) Haftnotizen in Form von Freunde-Episoden notieren. Freunde-Episoden beginnen immer mit dem "Wo". Denken Sie über den Tellerrand hinaus und überlegen Sie, wo diese Beispiele den aktuellen EventStorm beeinflussen. Handelt es sich um eine Lücke im aktuellen System, oder ist es eine Wissenslücke, die nicht mehr zu schließen ist, markieren Sie sie mit Hotspots, machen Sie sie deutlich!
An diesem Punkt, mit den Leuten im Raum, haben wir wahrscheinlich genug Einblick in den aktuellen Zustand. Jetzt können wir bereits sehen, wie sich ein begrenzter Kontext herausbildet oder wo sich die Systeme miteinander verstrickt haben und die Grenzen nicht explizit gemacht werden. Dieser erste Teil des Workshops wird etwa zwei bis drei Stunden in Anspruch nehmen, eine geringe Investition im Vergleich zu den gewonnenen Erkenntnissen. Wenn wir so viel Wissen über die Ist-Situation gesammelt haben, ist es vielleicht klug, den Workshop hier zu beenden und das erworbene Wissen im Schlaf zu verarbeiten.
Szenario
Nachdem wir nun das gesamte Ist-Wissen über das System erfasst haben, wollen wir dasselbe für die Soll-Situation tun. Für die Soll-Situation erstellen wir einen neuen Modellierungsbereich, in dem wir erneut EventStorming durchführen, eine neue Papierrolle verwenden und mit dem Storming von Domänenereignissen für die Soll-Situation beginnen.
Gehen Sie durch und konzentrieren Sie sich auf den schwierigen Teil
Sobald wir alle Ereignisse gestürmt haben, wollen wir dasselbe tun wie beim letzten Mal: die Ereignisse durchgehen, die Zeitachse durchsetzen und doppelte Domänenereignisse entfernen. Jetzt wollen wir uns auf den schwierigen Teil konzentrieren und herausfinden, wo die Komplexität liegt. Wir tun dies, indem wir ein neues Konzept einführen. Anstelle des langen rosafarbenen Sticky können wir auch den langen gelben Sticky für konsistente Geschäftsregeln verwenden. Wenn wir jede Regel auf einen Zettel schreiben, können wir sie später effizienter refaktorisieren, anstatt mehrere Regeln auf einen Zettel zu schreiben. Eine konsistente Geschäftsregel wird immer vor einem Domänenereignis stehen.
Wir wollen zuerst nach den konsistenten und eventuell konsistenten Geschäftsregeln (die gelben und violetten) suchen und uns auf diesen Teil konzentrieren. Machen Sie die Geschichte konsistent, indem Sie die anderen farbigen Stickies hinzufügen. Konzentrieren Sie sich auf die verwendete Sprache. Es ist wichtig, herauszufinden und zu sehen, wo Wörter mehrdeutig werden. Fügen Sie auch die Akteure hinzu, um deutlicher zu machen, wer für welchen Teil der Geschichte verantwortlich ist. All diese Informationen zusammengenommen sind das, worum es bei der Definition eines richtigen begrenzten Kontextes geht.
Beispielkarte
Wie beim Ist-Zustand verwenden wir wieder die Beispielzuordnung. Beginnen Sie wieder mit dem Storming-Teil, indem Sie die Beispiele auf einem grünen Klebezettel entweder neben dem EventStorm oder an einer separaten Wand auf einer anderen Papierrolle notieren. Nur dieses Mal gehen wir beim Beispiel-Mapping noch weiter, indem wir die Beispiele in vertikalen Reihen durch eine Geschäftsregel strukturieren. Schreiben Sie die Geschäftsregeln auf einen blauen Zettel oberhalb der vertikalen Reihe der Beispiele. Wichtig ist, dass Sie nur eine Geschäftsregel pro vertikaler Reihe haben. Nur eine Geschäftsregel bedeutet, dass bestimmte Beispiele mehrfach vorkommen können, sich aber eher auf eine andere Geschäftsregel konzentrieren.
© cucumber.io
Die Geschäftsregeln werden mit den Geschäftsregeln in Ihrem EventStorm übereinstimmen. Höchstwahrscheinlich werden Sie auch neue Geschäftsregeln finden, die Sie explizit machen müssen. Wenn dies der Fall ist, müssen Sie Ihre EventStorm mit den neu gewonnenen Informationen anpassen. Das Ziel beider Tools ist es, Wissen auszutauschen und komplexe Geschäftsbereiche zu erforschen. Achten Sie also darauf, dass Sie die beiden Tools nicht zu sehr aneinander anpassen.
Modellieren, zerlegen, formalisieren und codieren Sie die Sonde
Mit unserem neu erworbenen Wissen ist es nun an der Zeit, mit der Modellierung zu beginnen. Zunächst werden wir verschiedene Modelle untersuchen und sehen, wie sich die Modelle im Vergleich zu EventStorm und den Beispielen auf Ihrem Beispiel-Mapping schlagen. Versuchen Sie, mindestens drei Modelle zu finden und gehen Sie diese schnell durch. Sobald Sie ein brauchbares Modell gefunden haben, können wir unser Beispiel-Mapping zerlegen. Diskutieren Sie, welche Geschäftsregeln am wichtigsten sind und beginnen Sie mit der Formalisierung der Beispiele.
Mit unserem funktionsfähigen Modell und den formalisierten Beispielen können wir nun mit der Programmierung beginnen. Da wir anhand unserer formalisierten Beispiele wissen, was das System tun muss, ist es einfach, mit Hilfe der testgetriebenen Entwicklung kostengünstig einen Prototyp unseres Modells in Code zu schreiben. Auf diese Weise verfeinern wir kontinuierlich unsere Sprache und hinterfragen unser Modell.
Außerdem ist dieser Beitrag auf meiner persönlichen Blog-Seite veröffentlicht.
Verfasst von
Kenny Baas-Schwegler
A lot of knowledge is lost when designing and building software — lost because of hand-overs in a telephone game, confusing communication by not having a shared language, discussing complexity without visualisation and by not leveraging the full potential and wisdom of the diversity of the people. That lost knowledge while creating software impacts the sustainability, quality and value of the software product. Kenny Baas-Schwegler is a strategic software delivery consultant and software architect with a focus on socio-technical systems. He blends IT approaches like Domain-Driven Design and Continuous Delivery and facilitates change with Deep Democracy by using visual and collaborative modelling practices like Eventstorming, Wardley mapping, context mapping and many more. Kenny empowers and collaboratively enables organisations, teams and groups of people in designing, architecting and building sustainable quality software products. One of Kenny's core principles is sharing knowledge. He does that by writing a blog on his website baasie.com and helping curate the Leanpub book visual collaboration tool. Besides writing, he also shares experience in the Domain-Driven Design community as an organiser of Virtual Domain-Driven Design (virtualddd.com) and Domain Driven Design Nederland. He enjoys being a public speaker by giving talks and hands-on workshops at conferences and meetups.
Unsere Ideen
Weitere Blogs
Welche intrinsische Motivation Ihre Kollegen antreibt mit Moving Motivators
Welche intrinsischen Motivationsfaktoren gibt es bei Ihren Mitarbeitern? Die Mitarbeiter sind der wichtigste Teil eines Unternehmens, und Manager...
Irene de Kok
Optimierung von AWS Step Functions: Einblicke vom Amsterdam Summit
Gestern nahm ich am AWS Summit 2025 in Amsterdam teil, wo ich an einer Sitzung über AWS Step Functions teilnahm, die von Adriaan de Jonge, einem...
Simon Karman
Contact
Let’s discuss how we can support your journey.