Domain Message Flow Modeling
Visualisierung der Kommunikation zwischen Bounded Contexts
Im Jahr 2020 führte Nick Tune eine nützliche Idee in die Domain-Driven Design (DDD)-Gemeinschaft ein: eine Methode zur Visualisierung des Nachrichtenflusses (d.h. Befehle, Ereignisse und Abfragen) in einer Architektur mit begrenztem Kontext. Nick nennt seine Technik Domain Message Flow Modeling und einige der Hauptgründe für ihre Verwendung sind:
- Validierung neu entworfener Grenzen und Interaktionen durch Analyse und Aufdeckung der Kopplung.
- Günstige Entdeckung: Können wir versteckte Komplexität identifizieren, bevor wir mit der Implementierung beginnen?
- Analyse von IT-Landschaften durch Konzentration auf die Domäne und nicht auf bestehende Systemgrenzen.
Eine umfassende Einführung in das Domain Message Flow Modeling finden Sie unter https://github.com/ddd-crew/domain-message-flow-modelling.
Nick sagt, dass er stark vom C4-Modell und vom Domain Storytelling inspiriert wurde. Da Domain Storytelling eine vielseitige Technik ist, habe ich mich gefragt, ob sie für die Modellierung von Domain Message Flows angepasst werden kann. In der Software-Sprache würde man dies wahrscheinlich als "Rückport" bezeichnen. Dieser Artikel fasst die notwendigen Anpassungen zusammen. Ich hoffe, dass dies Domain Storytelling-Praktiker dazu ermutigt, Domain Message Flow Modeling auszuprobieren.
Eine piktografische Sprache für die Modellierung des Nachrichtenflusses in einem Bereich
Im Domain Storytelling unterscheiden wir zwischen verschiedenen Symbolen: Akteure, Arbeitsobjekte, Aktivitäten, Anmerkungen, Gruppen und Sequenznummern. Akteure und Arbeitsobjekte werden durch Symbole ausgedrückt und mit ihrer konkreten Bedeutung beschriftet. Die Konzepte des Domain Message Flow Modeling lassen sich auf die Bildsprache des Domain Storytelling abbilden, siehe Abbildungen unten.
Ich habe dieses Diagramm mit egon.io erstellt, einem Open-Source-Tool für Domain Storytelling. Allerdings hätte ich ein ähnlich aussehendes Bild auch mit Tools wie Miro oder einem Whiteboard mit Haftnotizen erstellen können. Die Prinzipien der Bildsprache wären dieselben gewesen (z. B. begrenzte Kontexte, die als Akteure modelliert sind), nur die Symbole und Beschriftungen hätten etwas anders ausgesehen.
Sie werden sich vielleicht fragen, warum bei der Modellierung von Bereichsnachrichtenflüssen zwischen begrenzten Kontexten und Systemen unterschieden wird. Nicks Argumentation - und ich vereinfache hier - ist, dass ein begrenzter Kontext etwas ist, das die Organisation kontrolliert (Benennung, Grenzen usw.), während die "Systeme" nicht in der Kontrollzone der Organisation liegen. Außerdem habe ich die Erfahrung gemacht, dass die Modellierung begrenzter Kontexte verhindert, dass man voreilige architektonische Schlüsse zieht (z. B. ob "Vertrieb", "Benachrichtigungen" und "Abrechnung" als Microservices implementiert werden sollten).
In meinem Beispiel verwende ich Annotationen zur Modellierung des Nachrichteninhalts (z. B. "order id", "items" und "payment method"). Dies ähnelt dem Format, das Nick als "separate Nachricht und Inhalt" beschreibt.
Der eigentliche Nachrichtenfluss wird mit Aktivitäten modelliert. In einer Domain Story wird eine Aktivität als Pfeil visualisiert und in der Regel mit einem Verb beschriftet. In einer "klassischen" Domain Story würde der erste Satz lauten: "Shopper bestellt über die Website". Aus Sicht des Nachrichtenflusses löst der Käufer jedoch den Befehl "Bestellung aufgeben" aus - die Absicht des Käufers wird Teil der Arbeitsobjekte (d. h. Ereignis, Befehl und Abfrage). Daher werden die Aktivitäten im obigen Beispiel nicht beschriftet; sie werden auf die Visualisierung des Nachrichtenflusses reduziert. Die Reihenfolge der Nachrichten wird durch Sequenznummern ausgedrückt.
Können Sie mir ein Beispiel geben?
Ein Domänen-Nachrichtenflussmodell zeigt das Verhalten von begrenzten Kontexten - es zeigt einen Prozess, nicht eine Struktur. Dieser Prozess wird anhand eines Beispiels illustriert. Im Domain Storytelling nennen wir das szenariobasierte Modellierung. "Eine Online-Bestellung aufgeben, wenn alle Artikel vorrätig sind" ist ein anderes Szenario als "eine Online-Bestellung aufgeben, wenn ein Artikel nicht vorrätig ist". Jedes Szenario wird in einem separaten Bild visualisiert und kann unterschiedliche Kontexte und Systeme darstellen.
Das Ziel der szenariobasierten Modellierung besteht nicht darin, alle möglichen Varianten abzudecken, sondern die wichtigsten - den 80 %-Fall, die häufigsten Varianten oder wichtige Fehlerfälle.
Wie die Bilder erstellt werden
Domain Storytelling kombiniert eine bildhafte Sprache mit einem Workshop-Format. Inwieweit das kollaborative Potenzial des Workshops auf das Domain Message Flow Modeling übertragen werden kann, hängt von der jeweiligen Situation ab. Die Zusammenarbeit in Workshops ist vor allem dann sinnvoll, wenn Sie Soll-Architekturen (mit kandidatengebundenen Kontexten) entwerfen wollen. Die Dokumentation einer bestehenden Architektur (Ist-Modellierung) könnte auch mit weniger Zusammenarbeit funktionieren.
Danksagung
Ich danke Nick Tune für die Durchsicht eines Entwurfs dieses Artikels.
Möchten Sie mehr über Domain Storytelling erfahren? Unser Buch ist in gedruckter Form und als E-Book erhältlich. Es ist Teil von Addison-Wesleys neuer Vaughn Vernon Signature Series. Besuchen Sie https://domainstorytelling.org/book für Kaufoptionen.