Blog
2 Tage im Leben eines Domain-Driven Design Trainees
Warum habe ich ein Domain-Driven Design (DDD) Foundations Training gemacht? Ich war schon immer ein großer Befürworter des kontinuierlichen Lernens und als Sozialwissenschaftler weiß ich, wie leicht wir in kognitiven Verzerrungen und Heuristiken gefangen sind. Deshalb bin ich davon überzeugt, dass es entscheidend ist, die eigenen Perspektiven, Meinungen und Urteile ständig zu hinterfragen. Und so bin ich bei der DDD-Schulung gelandet.
“Once we start judging, we stop learning.”
Für mich, Bereichsorientiertes Design (DDD) geht es um einen Weg - oder eine Methode, eine Technik, einen Ansatz oder was auch immer - zur Schaffung eines gemeinsamen Realitätssinns und zum Umgang mit sozio-technischer Komplexität. Es geht nicht um ein Ziel an sich - obwohl ich das sehr oft sehe, wie bei jedem anderen 'neuen Kind im Block' - sondern um ein Mittel zum Zweck. Es geht darum, gemeinsam etwas zu erreichen, gemeinsam mit Geschäftsexperten, Stakeholdern, UX-Experten, Testern und Entwicklern zu modellieren. Brechen Sie die Silos auf!
Ich war also ziemlich aufgeregt, an einem 2-tägigen Training von Kenny Baas-Schwegler teilzunehmen. Meine persönlichen Ziele waren:
- Gain more and new knowledge on DDD in general, and specifically on tactical patterns.
- Challenge my current knowledge, biases, and thinking patterns that I might be stuck in.
Tag 1 - Erlernen der Grundlagen von Domain-Driven Design (DDD)
Einführung in Domain-Driven Design
On a very early Wednesday morning, I was heading to Xebia HQ in Hilversum, where the training course would take place. Started with some coffee, chit-chat, and a little bit of waking up. We were with 8 people. Pretty soon, it got clear to me that this was a diverse group of people. Different backgrounds, interests, and nationalities. "This will be fun!", was my first thought.
Der Schulungsraum sah nicht wie ein typisches Klassenzimmer aus. Ich sah einige Papiere mit Zeichnungen an der Wand und einen riesigen Koffer mit Stickies, Markern, Sharpies - und allem anderen, nach dem mein 8-jähriges Ich verrückt geworden wäre.
[caption id="attachment_28431" align="aligncenter" width="257"]
My inner child jumped for joy when seeing this toolbox![/caption]
Nach einer kurzen Pause gingen wir mit ein paar Folien auf das Wesen des Domain-Driven Design ein, das oft auch als DDD bezeichnet wird. "Ich werde nicht das ganze Buch zitieren, aber ich werde einige Zitate und Referenzen nennen", sagte Kenny zu uns. Mir wurde schnell klar, dass dies keine Schulung sein würde, bei der man sich zurücklehnen und entspannen kann. Wir würden hauptsächlich auf den Beinen sein. Ein paar Hinweise sind hängen geblieben:
- Das Hauptproblem, das DDD löst, lautet: "Wie kann ich kleinere Modelle erstellen?
- Es wird immer ein Design geben, also sollten Sie sich damit befassen.
- Wir entwickeln Software gemeinsam - deshalb brauchen wir eine gemeinsame Geisteshaltung. Darum geht es bei DDD: eine einheitliche Sprache, ein gemeinsames Verständnis, soziale Wesen.
Der Sozialwissenschaftler in mir war froh, dass dies bestätigt wurde. Wie ich schon sagte, glaube ich, dass Domain-Driven Design ein Weg ist, mit Komplexität umzugehen, Abstraktion und spezifische Modelle für spezifische Lösungen zu schaffen. Als wir über Modelle sprachen, kam unsere teaminterne Diskussion über 'friet or patat' auf. Das Problem mit der Sprache ist natürlich, dass sie nicht konsistent und nicht für jeden gleich ist. Mit Domain-Driven Design versuchen wir, kleine Modelle mit einer konsistenten Sprache zu erstellen: mehrere begrenzte Sprachen, anstatt einer einzigen kanonischen Sprache.
EventStorming für eine gefälschte Domain
Bei diesem Training haben wir eine falsche Domäne verwendet, für die wir alle Experten waren: eine Domäne für Theaterbesuche. Das ist es, was wir modellieren würden. Kenny erklärte zunächst Modell Exploration Whirlpoolund begann mit Szenarien. Wir mussten eine Geschichte erzählen und konkret werden. Das ist genau der Punkt, an dem die kognitive Voreingenommenheit gewöhnlich einsetzt.
Ohne viel Theorie stürzten wir uns ins Getümmel. Mit einem braunen Papier, das die Zeit repräsentiert, hatten wir alle orangefarbene Klebepunkte und einen Scharfschreiber. Meine Gruppe teilte sich in 2 Gruppen zu je 4 Personen auf, jede mit ihrem eigenen braunen Papier.
Step 1 - Experiencing chaotic exploration
Und oh Mann, es ist chaotisch. Wir schrieben einzeln Domain-Ereignisse auf die orangefarbenen Klebezettel - die geschäftsrelevant (keine Datenbanken und technisches Zeug!) und in der Vergangenheit angesiedelt waren - und fügten sie dem braunen Papier hinzu. Es war ein aufschlussreicher und hochinteressanter Moment, wie jeder auf unterschiedliche Ereignisse kam. Wir haben alle unsere mentalen Modelle explizit gemacht, und das war ein großartiger Ausgangspunkt!
EventStorming - Mapping Domain Events[/caption]
Step 2 - Enforcing the timeline
Das war der Zeitpunkt, an dem wir begannen, über die Themen zu diskutieren. EventStorming geht es darum, gemeinsam eine gemeinsame Sprache zwischen verschiedenen Beteiligten zu entwickeln, um ein gemeinsames Verständnis von Prozessen und der zugrunde liegenden Software zu schaffen. Es lag an uns als Gruppe, eine Zeitleiste mit den Ereignissen zu erstellen, auf die wir uns alle einigen konnten. Das bedeutete, dass wir viele Male diskutieren und fragen mussten : "Was meinen Sie mit diesem Sticky?" Klebezettel wurden entfernt, neue wurden hinzugefügt und wir sprachen ständig darüber, was auf der Tafel stand. Dieser Ansatz verhinderte, dass wir uns auf persönliche Diskussionen über nicht explizite Themen einließen. Es schien zu einfach... Kenny ließ uns unser Ding machen. Er hat sich nicht eingemischt oder uns gelenkt, aber er hat aktiv zugehört. Ab und zu stellte Kenny einen anderen farbigen Zettel vor, der uns nur dabei half, mit den Problemen umzugehen, auf die wir gestoßen waren. Zum Beispiel pinke Klebezettel, um Hotspots zu kennzeichnen: Dinge, auf die wir nicht sofort eine eindeutige Antwort hatten, so dass wir sie markieren konnten, um sie zu einem späteren Zeitpunkt zu untersuchen. Auf diese Weise wurde eine Legende der Farben aufgebaut.
Step 3 - Finishing the storyline
Irgendwann waren wir mit unserem Zeitplan zufrieden. Zeit, einen Schritt zurückzutreten und nachzudenken. Kenny fragte uns dann, welche Unterschiede wir beim Vergleich der beiden braunen Papiere sahen. Es war sehr interessant zu sehen, wie 2 Gruppen eine Zeitleiste auf völlig unterschiedliche Weise strukturieren können. Das ist genau der Punkt: "Es gibt keine absolute Wahrheit. Es geht darum, dass Sie sich als Gruppe auf etwas einigen und daran festhalten." Eine Person erzählte die Geschichte auf der Grundlage der erzwungenen Zeitleiste, was uns half, den Prozess besser zu verstehen.
Step 4 - Playing by the rules
Zu diesem Zeitpunkt zeigte uns Kenny eine Prozesszeichnung mit noch mehr verschiedenfarbigen Stickies, woraufhin wir mit 'Prozessmodellierung EventStorming'. Aktionen, Systeme, Richtlinien, Informationen, Akteure... Es war alles dabei und wir begannen, den Prozess anhand dieser neuen Erkenntnisse zu gestalten. Es war wirklich erstaunlich zu sehen, wie viel man in so kurzer Zeit erreichen kann!
[caption id="attachment_28432" align="aligncenter" width="515"]
'Playing by the rules'[/caption]
From process modeling to software modeling
Nach einem wohlverdienten Mittagessen beginnen wir mit einem Energizer. Ein lustiges Spiel, bei dem 2 Gruppen gegeneinander antraten. Wir mussten ein Gespräch über bestimmte Themen in Gang halten, durften aber nur Fragen stellen. Wenn Sie zu lange brauchten, war die nächste Person in der Reihe an der Reihe. Das war genau das, was wir brauchten, um unser Mittagsschläfchen zu überwinden - und es hat großen Spaß gemacht!
Es gab sogar einen pädagogischen Aufhänger. Das Hinterfragen ist für DDD entscheidend. Sie können nicht von etwas ausgehen, sondern sollten immer Fragen stellen. Kenny führte uns in die Sokratische Befragung und erklärte uns, wie wir diese zum Beispiel beim EventStorming einsetzen können.
Auch wenn EventStroming ein wirklich nützliches und großartiges Werkzeug ist, ist es immer noch ein Werkzeug. Es hat blinde Flecken. Eine der Veranstaltungen, die wir auf die Karte gesetzt haben, beinhaltete zum Beispiel 'beste Plätze'. Was bedeutet 'beste'? Die Kombination von Tools für die visuelle Zusammenarbeit kann eine gute Möglichkeit sein, blinde Flecken und kognitive Verzerrungen zu überwinden.
"Combining visual collaboration tools can be a good way of conquering blind spots and cognitive bias."
Beispiel Mapping
Also begannen wir zu experimentieren mit Beispiel Mapping. Bei diesem Tool geht es darum, Bedeutung, Regeln und konkrete Beispiele zu hinterfragen. Ein großartiges Werkzeug für User Stories! Wir begannen mit der Ausarbeitung unserer Regeln und Beispiele und visualisierten unsere Beispiele, wodurch die Dinge wirklich konkreter wurden.
Das Ende von Tag 1 nahte und unsere kognitive Belastung stieß an ihre Grenzen. Im letzten Teil des Tages mussten wir ein echtes Modell erstellen. Teil 2 des Model Exploration Whirlpools: Modell.
Domain-Driven Design ist normalerweise objektorientiert, also haben wir uns dafür entschieden. Unsere Herausforderung bestand darin, ein bestimmtes System zu modellieren, das Teil des Prozesses war, den wir während des EventStorm definiert hatten. Alles, was wir dazu brauchten, waren ein Whiteboard, Marker und unser visualisierter Prozess. Wir zeichneten, wir diskutierten, wir verfeinerten. Sobald beide Gruppen mit ihrem Modell zufrieden waren, sprachen wir miteinander über die Modelle. Nochmals: Es gab keine absolute Wahrheit, alle Modelle waren falsch. Alles, was zählte, war, das am wenigsten falsche Modell zu erstellen, auf das wir uns alle einigen konnten.
Und das war's für Tag 1. Wir beendeten den Tag mit einem Check-Out und notierten auf Klebezetteln (was sonst...), was uns am ersten Tag "begeistert" hatte und "wie wäre es mit...". Dies würde unser Ausgangspunkt für den zweiten Tag sein. Aber zuerst: eine gute Nachtruhe!
[caption id="attachment_28437" align="aligncenter" width="350"]
Modell Erkundung Whirlpool[/caption]
Tag 2 - Vertiefung in Domain-Driven Design
Unser zweiter Tag begann mit einem Kaffee und einem Rückblick auf den ersten Tag. Die Energie war wieder da, die Gruppe war aufgeregt und freute sich auf den zweiten Tag. Im Schulungsraum begannen wir mit einem 'formellen' Check-in, während wir darüber nachdachten, was auf der 'Wow'-Tafel und der 'How about'-Tafel steht.
Danach erzählte Kenny ein wenig mehr über sich selbst und erzählte einige persönliche Geschichten. Zum Beispiel darüber, wie er in der 'IT-Welt' gelandet ist und wie das mit dem zusammenhängt, was wir hier tun. Seine Geschichte über Spaghetti-Strukturen, die zu einem großen Schlammball führen, fand Anklang und bestätigte, warum man immer das System als Ganzes verbessern sollte, wenn man erfolgreich sein will. Blindflug bei Agile, Scrum, DevOps, Microservices...
"Sie können ein Modell kopieren, aber nicht einfügen."
Wenn Sie sich an etwas aus diesem Beitrag erinnern wollen, dann an dieses Zitat. Schreiben Sie es auf eine Kachel und hängen Sie es an einer gut sichtbaren Stelle auf. Es gibt universelle Prinzipien, die Sie auf jeden Fall anwenden können, aber Sie müssen darauf achten, wie sie sich auf Ihre eigene Kultur auswirken. Und das ist der Punkt, an dem die Dinge oft den Bach runtergehen, weil die Leute denken: "Das funktioniert bei Google/Spotify, also wird es auch bei uns funktionieren!" Überdenken Sie das.
Big Picture EventStorming
Lose gekoppelte Architekturen, das ist es, was wir alle wollen. Funktionsübergreifende Produktteams, die nach Fähigkeiten organisiert sind, so dass wir in unseren Domänen die geringste Kopplung haben. Klingt großartig. Aber wie kommen wir dahin? Dies ist der strategische Teil von DDD, bei dem es darum geht, den Kontext zu erhalten und zu gestalten.
Der beste Weg, hier anzufangen, ist wieder EventStorming. Diesmal jedoch auf einer höheren Ebene: Big Picture EventStorming. Für diese Übung bekamen wir alle Rollen zugewiesen, die wir im EventStorm spielen mussten. Ich habe mich für die Rolle 'Inhalt' entschieden, weil das ein kleines Stückchen Komfort in der Nicht-Komfortzone war, in der ich mich immer noch befand.
Nachdem wir alle eine Beschreibung unserer Rolle erhalten hatten, begannen wir damit, die für uns relevanten Domänenereignisse aufzuschreiben und sie wiederum auf das braune Papier zu legen. Nun, das führte zu einem totalen Chaos. Kenny war jedoch ein hervorragender Moderator, weshalb er gerade dann neue Hilfsmittel einführte, als wir selbst merkten, dass wir etwas brauchten, um uns aus dem Chaos herauszuführen. Schlüsselereignisse wie Systemgrenzen, zeitliche Meilensteine, aufkommender Kontext und Schwimmbahnen helfen uns, diesen Prozess zu visualisieren. Ich kann mir gut vorstellen, wie diese Workshops und Visualisierungen dabei helfen können, strategische Entscheidungen in der 'realen Welt' zu treffen.
Ziemlich bald wurde uns klar, dass es ziemlich schwierig ist, bei Ihrer Rolle und deren Perspektiven zu bleiben. Sie sind versucht, aus Ihrer 'echten' Rolle und dem Wissen, das Sie haben, heraus zu berichten. Gleichzeitig hilft Ihnen der Zwang, in eine andere Rolle zu schlüpfen, kognitive Verzerrungen zu überwinden. Der offensichtliche Vorteil dieses Big Picture EventStorming war, dass wir - wieder einmal - ein gemeinsames Gefühl für die Realität geschaffen haben.
Beginnen Sie damit, den Prozess abzubilden. Durch all die verschiedenen Rollen gewinnen Sie mehr Einblick und die Abhängigkeiten werden klarer. Wenn Sie das alles erfasst haben, können Sie damit beginnen, Systeme und Möglichkeiten auf den vereinbarten Prozess abzustimmen. Das ist auch eine gute Möglichkeit, Hotspots zu identifizieren.
[caption id="attachment_28433" align="aligncenter" width="528"]
Big Picture EventStorming[/caption]
Kontext-Mapping
Kommen wir nun zum nächsten strategischen Entscheidungsinstrument, das uns helfen könnte, auf der Grundlage der Ergebnisse des Big Picture EventStorm einen Kontext zu erstellen: Context Mapping. Mit Stiften und einem Whiteboard bewaffnet, begannen wir, Kreise zu zeichnen und ihre Beziehungen zu definieren. Wir verwendeten die auf dem braunen Papier identifizierten Prozesse als unsere Kreise: Marketing, Budgetierung, Buchhaltung, usw. Und wir begannen, ihre Beziehungen zu zeichnen. Leider wurden wir ein wenig frustriert, als wir feststellten, dass so ziemlich alles miteinander zusammenhing.
An dieser Stelle kam Kenny ins Spiel und leitete unseren nächsten Schritt ein: die Destillation des Kerns. Wir identifizierten unsere Kerndomäne, unterstützende Domänen und generische Domänen. Was war unser Geldbringer? Wie sollten wir unsere Teams organisieren? Worauf wollten wir unsere Energie konzentrieren? Das scheint alles ziemlich trivial zu sein, aber durch die Visualisierung - wir hatten buchstäblich etwas, auf das wir zeigen konnten, während wir diskutierten - wurde es für uns einfacher, Entscheidungen zu treffen.
Wir gehen ein wenig auf das Cynefin-Framework ein, was an diesem Punkt der Schulung absolut sinnvoll war. Der Umgang mit Komplexität und Entscheidungsfindung durch Kenntnis der Domäne, in der Sie sich befinden. Wir haben dies mit Domain-Driven Design in Verbindung gebracht - wie Sie taktische Muster wahrscheinlich nicht in einer offensichtlichen Domäne verwenden sollten, wie DDD in komplexen Domänen glänzt und dass EventStorming hauptsächlich in komplizierten und komplexen Domänen funktioniert. Eine großartige Möglichkeit, die Theorie in die Praxis umzusetzen!
Context Mapping - Strategische Muster
Kenny erklärte dann die möglichen Beziehungen zwischen Kontexten. Das war ein bisschen abstrakt und verwirrend, denn es gibt ziemlich viele davon. Wir versuchten, strategische Muster auf der soeben erstellten Kontextkarte zu erkennen, und waren (wieder einmal) etwas frustriert. Kenny beruhigte uns, dass dies normal sei und man nur viel Übung brauche. Es wird auch einfacher, wenn Sie anfangen, mit Ihren 'echten' Domänen und Kontexten zu üben. Das Wichtigste war, dass wir verstanden haben, dass Lösungen von diesen strategischen Mustern abhängen. Wenn Sie wissen, wie Ihre Domänen aussehen (auch in Bezug auf die Kommunikation), können Sie Ihre Lösungen besser auswählen.
Nach dem Mittagessen war es wieder Zeit für einen Energizer - dieses Mal das 'Happy Salmon Spiel'. Zum Glück hat hier niemand Fotos gemacht...
Begrenzte Kontexte und Aggregate
Dann haben wir uns ein wenig mit der Theorie über entstehende begrenzte Kontexte befasst. Wie wir sie anhand unserer braunen Papiere, der Schwimmbahnen, der Personen auf dem braunen Papier, der Personen im Raum und der Körpersprache erkennen können. Dies sind alles verschiedene Möglichkeiten, begrenzte Kontexte zu erkennen. Nachdem wir darüber gesprochen hatten, gingen wir zum Leinwand für begrenzte Kontextedie wir verwenden können, um Software richtig zu entkoppeln.
Der Bounded Context Canvas schien ziemlich einfach zu sein, aber er ist tatsächlich ziemlich schwierig zu machen - was ein wiederkehrendes Thema in dieser Schulung zu sein schien. Auch wenn Sie es gerne einfach halten würden, sind Sie doch versucht, eine Menge in diesen Canvas aufzunehmen. Unsere 2 Gruppen haben völlig unterschiedliche 'Modelle' entwickelt. In unserer Gruppe haben wir etwa 15 Minuten damit verbracht, die Begriffe "Reservierung", "Sitzplatz" und "Ticket" zu definieren - ich mache Ihnen nichts vor. Auch das klingt trivial, aber es war wirklich schwierig und wichtig, bevor wir zum nächsten Schritt übergingen.
Nachdem wir die Leinwand fertiggestellt hatten, begannen wir mit dem Modellieren. Wir waren alle ziemlich zuversichtlich und überzeugt, dass dies einfacher sein würde als am ersten Tag. Junge, Junge, da haben wir uns geirrt... Wir blieben im Modell vom Vortag stecken und fanden uns in denselben Diskussionen über Entitäten und Wertobjekte wieder. Vielleicht lag es daran, dass wir mehr Wissen erworben hatten. Schließlich ist Unwissenheit ein Segen, nicht wahr?
Geben Sie Aggregate ein! Implizit haben wir bereits über Aggregate gesprochen. Wir wussten nur nicht, dass es Aggregate genannt wurde. Erst als wir merkten, dass wir etwas Zusätzliches brauchten, um sicherzustellen, dass die Geschäftsregeln eingehalten wurden, führte Kenny Aggregate ein. Er erörterte einige theoretische Aspekte, stellte sein Modell vor und wir versuchten erneut, verschiedene Modelle mit verschiedenen Aggregaten zu erstellen. Unterm Strich mussten wir klein anfangen und akzeptieren, dass alle Modelle falsch waren. Wir mussten nur das am wenigsten falsche Modell finden. So sind wir zu lose gekoppelten Architekturen gekommen.
[caption id="attachment_28435" align="aligncenter" width="458"]
Lektion gelernt: Je mehr Stickies auf dem Boden liegen, desto besser sind Ihre Diskussionen und Ergebnisse ;-) [/caption]
Abschließende Gedanken zu Domain-Driven Design
Das war's dann wohl! Zwei intensive Tage, aber irgendwie waren alle noch voller Energie. Das ist das Verdienst unseres Trainers Kenny. Mit seiner Art zu trainieren hat er dafür gesorgt, dass alle mitmachen und das hohe Energieniveau beibehalten.
Pro-Tipp: Wenn Sie nicht gerne viel aufstehen, sich bewegen und aktiv lernen, ist diese Schulung vielleicht nicht Ihr Ding. Aber ehrlich gesagt war dies eine der besten Schulungen, an denen ich je teilgenommen habe, denn es war ein aktiver Zustand, der verlangt wurde. Einige Schulungen hatten obligatorische interaktive Teile, aber die Domain-Driven Design-Schulung war etwas völlig Neues. Kein Klassenzimmertraining mit langweiligen Folien und viel Theorie, sondern einfach die Hände schmutzig machen und aus den eigenen Fehlern lernen - oder vielleicht auch aus den eigenen Schwierigkeiten. Meiner persönlichen Meinung nach ist das die beste Art des kontinuierlichen Lernens!
l
o
g
/
Verfasst von
Evelyn van Kelle
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