Vom Post-it zum Bounded Context: Wie detailliertes Event Storming echte Architektur schafft
Im Big-Picture-Event-Storming, das ich im vorherigen Beitrag beschrieben habe , entsteht ein erster Überblick über die Fachdomäne. Zentrale Ereignisse, wichtige Akteure und grobe Prozessketten werden sichtbar. Bereits in dieser Phase lassen sich erste Kandidaten für mögliche Fachkontexte erkennen – oft noch unscharf, aber als wertvolle Orientierung für die weitere Modellierung.
Obwohl das sogenannte Big-Picture-Event-Storming in der DDD-Community inzwischen weit verbreitet ist, beobachten wir häufig, dass der Prozess genau an dieser Stelle auch direkt wieder beendet wird.
Bei uns wird dieser Ansatz jedoch bewusst weitergeführt. In diesem Artikel wird im Detail erläutert, wie wir dabei vorgehen.
Ich demonstriere, wie sich aus dem detaillierteren Event Storming – insbesondere aus Process Modeling und dem explorativen Arbeiten an den Events – robuste Aggregates ableiten lassen, die wiederum die Grundlage für tragfähige Bounded Contexts bilden. Wir betrachten typische Muster, Stolpersteine und praktische Hinweise aus realen Migrationsprojekten, insbesondere wenn die vorhandenen Legacy-Strukturen historisch gewachsen und undurchsichtig geworden sind. Unser Ziel ist die Entwicklung eines Modells, das sowohl fachlich als auch technisch auf dem neuesten Stand ist. Durch die Implementierung einer klaren technischen Modularisierung möchten wir den Grundstein für eine nachhaltige Modernisierung legen.
Mit Process Modelling zu den Aggregates
Der Big-Picture-Workshop ist ein hervorragender Einstieg in die Fachlichkeit – aber er bleibt, wie beschrieben auf einer hohen Flughöhe, die nicht geeignet ist, die Datenflüsse zu analysieren, um einen sinnvollen Service-Schnitt durchzuführen. Ein Workshop, der sehr gut dazu geeignet ist, zu ermitteln, wo welche Daten benötigt werden (und warum), ist der Process Modelling Workshop. Für das Gelingen des Big-Picture Event Stormings halten wir es für wichtig, dass alle Personen im selben Raum sind, weil es dabei auch um Dynamiken in der Gruppe geht. Beim Process Modelling ist das nicht mehr so wichtig, so dass es durchaus digital stattfinden.
Während das Big-Picture-Event-Storming neben den Events maximal noch Personen (“People”) und Externe Systeme modelliert, werden diese Bausteine beim Process Modelling noch durch Commands, Read Model, Policy, UI und Aggregates ergänzt.
Aktionen durch Commands modellieren
Commands werden mit blauen Post-Its gekennzeichnet und stellen Aktionen dar, die durch eine Person oder eine Policy ausgelöst werden(z.B. „Zur Kasse gehen“).
Policies (mit lila Post-Its) sind Geschäftsregeln (z. B. Validierungen, Prüfregeln, Entscheidungen), die als Reaktion auf ein Eventausgeführt werden und wie geschrieben, ein Command auslösen. Commands werden immer entweder auf einem Aggregate oder auf einem externen System ausgeführt. Durch ihre Ausführung wird immer ein Event ausgelöst. Dabei ist es wichtig, dass die Beziehung zwischen Commands und Events nicht immer eine 1:1-Beziehungsein muss, so können z.B. mehere Commands („Angezeigte Standard-Lieferadresse bestätigen“, „Lieferadresse aus Liste auswählen“, „Lieferadresse eingeben“) zu ein und demselben Event führen („Lieferadresse festgelegt“) oder ein Command(„Zahlart auswählen“) kann zu mehreren alternativen Events führen(„Kreditkartenzahlung ausgewählt“, „Überweisung ausgewählt“). Mehrere Commands wählt man immer dann, wenn sich die Eingabedaten von Command zu Command unterscheiden. Mehrere Events entstehen immer dann, wenn der Ablauf je nach Event unterschiedlich weiter geht.
Datenabhängigkeiten durch Read Models identifizieren
Wenn Commands durch Personen ausgelöst werden, geschieht das häufig mit einem Read Model als Eingabe. Das Read Model sind Daten, die der Person potenziell in einer UI angezeigt werden, insbesondere aber dient das Read Model als Parameter für das Command. Entstanden ist das Read Model irgendwann auch durch ein Event.
Z.B. hat der Kunde irgendwann seine Standard-Adresse aus gewählt. Diese dient dann dem Command „Standard-Lieferadresse bestätigen“ als Input.
Finden von Aggregates
Wir haben mit diesem Prozess im Prinzip im Vorbei gehen die Aggregates unserer Applikation gefunden, indem wir sie einfach zwischen alle Commands und Events hängen, die sich nicht auf ein externes Systembeziehen.
Im Software-Design Schritt sammeln wir nun diese Aggregates aus dem Process Modelling ein und hängen die Commands, die auf dem Aggregate operieren und die Events, die daraus resultieren, darunter. Hierzahlt es sich aus, wenn wir das Process Modelling digital (z.B.) auf einem Miro-Board durchgeführt haben, weil Zettel dann kopiert werden können. Die einzige Entscheidung, die wir nun treffen müssen, ist, ob es sich bei zweigelben Zetteln im Process Modelling um dasselbe Aggregate handelt oder um unterschiedliche. Nimmt man das Aggregate, auf dem das Command „Zahlartauswählen“ ausgeführt wird zusammen mit den Aggregates von „Standard Rechnungsadresse auswählen“ und „Standard Lieferadresse auswählen“, so erscheint es sinnvoll, diese zusammen mit den jeweiligen Events unter ein gemeinsames Aggregate (z.B. „Kaufangebot“) zu hängen.
Im zweiten Schritt identifizieren wir die Daten, die durch die Commands geändert werden und hängen sie unter das Aggregate. In diesem Fall sind das Zahlungsinformationen und Rechnungs- und Lieferadresse des Angebots.
Eine entscheidende Feststellung dabei ist, dass es sich bei den hier entstehenden Adressen in diesem Fall zwar technisch um die Standard-Rechnungs-und Lieferadresse handeln könnte. Fachlich ist das aber nicht der Fall. Fachlich ist nämlich unerheblich, ob es die Standard-Rechnungsadresse ist, die für dieses konkrete Kaufangebot festgelegt wurde oder ob es eine andere Adresse aus der Liste des Kunden ist oder ob der Kunde sie extra eingegeben hat.
Und hier kommen wir zu einem entscheidenden Unterschied zur oben beschriebenen SOA-Welt. Dort hätte es eventuell einen Address-Service gegeben und dieselbe Adresse wäre Standard-Rechnungsadresse und Adresse verschiedener Aufträge gewesen.
Bei unserer der Modellierung der Aggregates handelt es sich um unterschiedliche Adressen. Das ist fachlich auch deshalb sinnvoll, weil sich die Standard-Lieferadresse des Kunden ja durchaus ändern kann während der Auftrag unterwegs ist. Die Lieferadresse des Auftrags sollte sich dadurch aber nicht ändern. Was in einem Address-Service aufwendig implementiert werden müsste, ist hier per Design gegeben.
Dies war der letzte Artikel von der fachliche Blogreihe von Arne. Wir teilen gerne unser Wissen mit euch. Bleibt gespannt wer über welches Thema demnächst schreiben wird.
Ich demonstriere, wie sich aus dem detaillierteren Event Storming – insbesondere aus Process Modeling und dem explorativen Arbeiten an den Events – robuste Aggregates ableiten lassen, die wiederum die Grundlage für tragfähige Bounded Contexts bilden. Wir betrachten typische Muster, Stolpersteine und praktische Hinweise aus realen Migrationsprojekten, insbesondere wenn die vorhandenen Legacy-Strukturen historisch gewachsen und undurchsichtig geworden sind. Unser Ziel ist die Entwicklung eines Modells, das sowohl fachlich als auch technisch auf dem neuesten Stand ist. Durch die Implementierung einer klaren technischen Modularisierung möchten wir den Grundstein für eine nachhaltige Modernisierung legen.
Mit Process Modelling zu den Aggregates
Der Big-Picture-Workshop ist ein hervorragender Einstieg in die Fachlichkeit – aber er bleibt, wie beschrieben auf einer hohen Flughöhe, die nicht geeignet ist, die Datenflüsse zu analysieren, um einen sinnvollen Service-Schnitt durchzuführen. Ein Workshop, der sehr gut dazu geeignet ist, zu ermitteln, wo welche Daten benötigt werden (und warum), ist der Process Modelling Workshop. Für das Gelingen des Big-Picture Event Stormings halten wir es für wichtig, dass alle Personen im selben Raum sind, weil es dabei auch um Dynamiken in der Gruppe geht. Beim Process Modelling ist das nicht mehr so wichtig, so dass es durchaus digital stattfinden.
Während das Big-Picture-Event-Storming neben den Events maximal noch Personen (“People”) und Externe Systeme modelliert, werden diese Bausteine beim Process Modelling noch durch Commands, Read Model, Policy, UI und Aggregates ergänzt.
Aktionen durch Commands modellieren
Commands werden mit blauen Post-Its gekennzeichnet und stellen Aktionen dar, die durch eine Person oder eine Policy ausgelöst werden(z.B. „Zur Kasse gehen“).
Policies (mit lila Post-Its) sind Geschäftsregeln (z. B. Validierungen, Prüfregeln, Entscheidungen), die als Reaktion auf ein Eventausgeführt werden und wie geschrieben, ein Command auslösen. Commands werden immer entweder auf einem Aggregate oder auf einem externen System ausgeführt. Durch ihre Ausführung wird immer ein Event ausgelöst. Dabei ist es wichtig, dass die Beziehung zwischen Commands und Events nicht immer eine 1:1-Beziehungsein muss, so können z.B. mehere Commands („Angezeigte Standard-Lieferadresse bestätigen“, „Lieferadresse aus Liste auswählen“, „Lieferadresse eingeben“) zu ein und demselben Event führen („Lieferadresse festgelegt“) oder ein Command(„Zahlart auswählen“) kann zu mehreren alternativen Events führen(„Kreditkartenzahlung ausgewählt“, „Überweisung ausgewählt“). Mehrere Commands wählt man immer dann, wenn sich die Eingabedaten von Command zu Command unterscheiden. Mehrere Events entstehen immer dann, wenn der Ablauf je nach Event unterschiedlich weiter geht.
Datenabhängigkeiten durch Read Models identifizieren
Wenn Commands durch Personen ausgelöst werden, geschieht das häufig mit einem Read Model als Eingabe. Das Read Model sind Daten, die der Person potenziell in einer UI angezeigt werden, insbesondere aber dient das Read Model als Parameter für das Command. Entstanden ist das Read Model irgendwann auch durch ein Event.
Z.B. hat der Kunde irgendwann seine Standard-Adresse aus gewählt. Diese dient dann dem Command „Standard-Lieferadresse bestätigen“ als Input.
Finden von Aggregates
Wir haben mit diesem Prozess im Prinzip im Vorbei gehen die Aggregates unserer Applikation gefunden, indem wir sie einfach zwischen alle Commands und Events hängen, die sich nicht auf ein externes Systembeziehen.
Im Software-Design Schritt sammeln wir nun diese Aggregates aus dem Process Modelling ein und hängen die Commands, die auf dem Aggregate operieren und die Events, die daraus resultieren, darunter. Hierzahlt es sich aus, wenn wir das Process Modelling digital (z.B.) auf einem Miro-Board durchgeführt haben, weil Zettel dann kopiert werden können. Die einzige Entscheidung, die wir nun treffen müssen, ist, ob es sich bei zweigelben Zetteln im Process Modelling um dasselbe Aggregate handelt oder um unterschiedliche. Nimmt man das Aggregate, auf dem das Command „Zahlartauswählen“ ausgeführt wird zusammen mit den Aggregates von „Standard Rechnungsadresse auswählen“ und „Standard Lieferadresse auswählen“, so erscheint es sinnvoll, diese zusammen mit den jeweiligen Events unter ein gemeinsames Aggregate (z.B. „Kaufangebot“) zu hängen.
Im zweiten Schritt identifizieren wir die Daten, die durch die Commands geändert werden und hängen sie unter das Aggregate. In diesem Fall sind das Zahlungsinformationen und Rechnungs- und Lieferadresse des Angebots.
Eine entscheidende Feststellung dabei ist, dass es sich bei den hier entstehenden Adressen in diesem Fall zwar technisch um die Standard-Rechnungs-und Lieferadresse handeln könnte. Fachlich ist das aber nicht der Fall. Fachlich ist nämlich unerheblich, ob es die Standard-Rechnungsadresse ist, die für dieses konkrete Kaufangebot festgelegt wurde oder ob es eine andere Adresse aus der Liste des Kunden ist oder ob der Kunde sie extra eingegeben hat.
Und hier kommen wir zu einem entscheidenden Unterschied zur oben beschriebenen SOA-Welt. Dort hätte es eventuell einen Address-Service gegeben und dieselbe Adresse wäre Standard-Rechnungsadresse und Adresse verschiedener Aufträge gewesen.
Bei unserer der Modellierung der Aggregates handelt es sich um unterschiedliche Adressen. Das ist fachlich auch deshalb sinnvoll, weil sich die Standard-Lieferadresse des Kunden ja durchaus ändern kann während der Auftrag unterwegs ist. Die Lieferadresse des Auftrags sollte sich dadurch aber nicht ändern. Was in einem Address-Service aufwendig implementiert werden müsste, ist hier per Design gegeben.
Dies war der letzte Artikel von der fachliche Blogreihe von Arne. Wir teilen gerne unser Wissen mit euch. Bleibt gespannt wer über welches Thema demnächst schreiben wird.
