Erweitern des Bounded Context Canvas mit BDD-Beispielen

Seit Nick Tune die Welt mit dem Bounded Context Canvas bekannt gemacht hat, baue ich ihn in meine Workshops und Schulungen ein. Nick sieht die Leinwand als Checkliste für die Gestaltung unserer Bounded Context Leinwand. Für mich ist es auch ein perfektes Visualisierungstool, um den Bounded Context deutlich zu machen. Das Einzige, was mir fehlt, sind Beispiele in Form von Akzeptanzkriterien, die ich während unseres verhaltensgesteuerten Entwicklungsablaufs entdeckt und schließlich formalisiert habe. In diesem Beitrag erkläre ich, wie ich das Bounded Context Canvas mit BDD-Beispielen aus dem Example Mapping erweitert habe, um zu zeigen, wie man das Verhalten eines Bounded Contexts formalisiert.

Wie gestalten wir Bounded Contexts mit EventStorming

Wie Sie in Nick Tune's Beitrag lesen können, verwendet er das folgende Rezept:

• Big Picture EventStorming (mind. 1 Stunde)
• Modellierung des Kandidatenkontextes (min. 30 Minuten)
• Modellierung des Nachrichtenflusses im Bereich (min. 30 Minuten)
• Bounded Context Canvas (mind. 90 Minuten)
• Verfeinerte Kontextexterkundung (min. 45 Minuten)

Ich gehe ähnlich vor, nur dass ich in der Regel mit EventStorming auf Prozess- oder Designebene in der Phase der Modellierung des Domänennachrichtenflusses beginne und nicht mit dem Domain Storytelling. Oder ich mache das nach dem Rezept, das Nick erwähnt, um meine Bounded Contexts noch weiter zu verfeinern. Welches und in welcher Reihenfolge Sie es verwenden, hängt stark von der Situation ab, in der Sie sich befinden. Beide Situationen habe ich bereits genutzt und sie haben funktioniert. Die Leute wissen, dass ich Tools und Rezepte gerne kombiniere, je nachdem, was benötigt wird und was mir mein Bauchgefühl im Moment sagt.

Aus EventStorming habe ich eine Reihe von Heuristiken gewonnen, die mir bei der Gestaltung von Bounded Context helfen. Ich möchte Ihnen ein naives Beispiel für einen Vergabeprozess für ein Kino geben:

Ich habe dieses Beispiel schon einmal verwendet. Es ist zwar nicht ganz richtig, aber es ist perfekt, um zu erklären, worauf wir hinauswollen. Dieses Ergebnis des EventStorming ist normalerweise die erste Iteration bei einer EventStorming-Sitzung. Von hier aus ist eine Heuristik, die ich verwende: Entwerfen Sie begrenzte Kontexte um Richtlinien herum. Nehmen wir also an, wir möchten einen Bounded Context für die Zuweisung entwerfen.

So füllen Sie den Bounded Context Canvas aus

Oben sehen Sie den ersten Entwurf des Bounded Context Canvas, ausgefüllt für Zuweisungen. Achten Sie nicht auf die strategische Einteilung, ich werde in diesem Beitrag nicht darauf eingehen. Sie können alles darüber in Nick Tunes Beitrag lesen! Wie Sie sehen, habe ich den Canvas anhand des Ergebnisses des EventStorm ausgefüllt. Es ist noch nicht vollständig, aber das ist jetzt und für das Beispiel nicht wichtig.

Der Bedarf an Beispielen

Bevor wir nun damit beginnen, unser Domänenmodell auf der Grundlage der großen Entdeckungen zu entwerfen, die wir während dieses Prozesses gemacht haben, benötigen wir Akzeptanzkriterien in Form von Beispielen. Das Bounded Context-Muster ist ein autonomes Muster und muss daher bestimmte Verhaltensweisen in Form von Beispielen eigenständig behandeln.

Ein Zeichen für eine enge Kopplung innerhalb einer Anwendungsarchitektur ist die Notwendigkeit von End-to-End-Tests, d.h. ein Beispiel zu testen und dafür mehrere begrenzte Kontexte zu benötigen. Diese End-to-End-Tests sind ein großes Anti-Muster bei der kontinuierlichen Bereitstellung und auch ein großes Anti-Muster beim Domain-Driven Design. Das bedeutet nicht, dass Sie nicht mehrere Bounded Contexts haben können, um einen Wertstrom zu unterstützen. Es bedeutet nur, dass wir uns nicht genug Mühe gegeben haben, unsere Bounded Contexts für Autonomie zu entwerfen.

Um die Beispiele für einen Bounded Context zu entdecken und schließlich zu formalisieren, verwende ich gerne eine Technik namens Example Mapping. Ich habe schon einmal darüber geschrieben, wie man EventStorming mit Example Mapping kombiniert und wie der Wechsel des Tools Ihnen helfen kann, Vorurteile zu bekämpfen, die in Tools stecken, die sicherstellen, dass Sie nicht unseren Millionen-Dollar-Fehler machen.

Beispiel Mapping

Oben sehen Sie eine unfertige Beispiel-Map, die Ihnen jedoch eine Vorstellung davon vermittelt, dass das Umschalten eines Tools dazu beitragen kann, noch mehr über unsere Domäne zu erfahren. Es ist wichtig, dass Sie während des Example Mappings immer wieder die Sprache des Fachgebiets verwenden und darüber iterieren. Ich sammle die Fachsprache und die Konzepte auch gerne auf Karteikarten, denn das sind Anhaltspunkte für unser Fachmodell.

Ausgehend von unserem Example Mapping können wir damit beginnen, unsere Akzeptanzkriterien als Szenarien zu formalisieren, die auf den von uns entdeckten Beispielen basieren. Ich verwende in dieser Phase gerne Gherkin, die Sprache von EventStorming:

Gegebene spezifische Domain Events geschehen
Wenn ich den Befehl X
Dann erwarte ich dieses Domain Event

Es gibt noch mehr Kombinationen, die Sie verwenden können, beschränken Sie sich nicht auf das Gurkenformat.

Erweitern des Bounded Context Canvas

Indem wir die formalisierten Szenarien zum Bounded Context Canvas hinzufügen, wissen wir, was unser Bounded Context-Modell erfüllen muss. Anhand dieser Szenarien können wir leicht erkennen, welches Verhalten unser Bounded Context lösen muss. Die Verwendung des Bounded Context Canvas als lebende Dokumentation, die für alle sichtbar ist, hilft dabei, den Bounded Context greifbarer zu machen.

Ein weiterer Vorteil der Szenarien ist, dass wir nach dem Entwurf unseres Domänenmodells direkt zu Outside-in TDD übergehen können, um unser Domänenmodell zu implementieren. Wenn wir die Szenarien als unsere Unit-Tests mit schnellem Feedback verwenden, erhalten wir mehr Einblicke in unser Design, wodurch wir erfahren, wie entkoppelt und flexibel unser Modell ist. Wir haben schnelles und unmittelbares Feedback, um unser Bounded Context Design zu überprüfen und anzupassen.

In meinem nächsten Blogbeitrag zeige ich Ihnen, wie wir von einem vorgeschlagenen Domänenmodell und formalisierten Szenarien zur Modellierung mit Responsibility-Driven Development und zur Implementierung mit Outside-in TDD übergehen können.

Außerdem ist dieser Beitrag auf meiner persönlichen Blog-Seite veröffentlicht.