In vielen Legacy-Systemen und komplexen Softwareprojekten ist die Entkopplung von Fachbereichen eine der größten Herausforderungen. Änderungen an einer Stelle können unerwartete Auswirkungen an anderer Stelle haben, und die Architekturwächst oft unübersichtlich mit der Zeit.
Genau hier setzt Domain-Driven Design(DDD) an: Es bietet einen strukturierten Ansatz, um fachliche Zusammenhänge zu verstehen und die Software in klar abgegrenzte Bounded Contexts zu gliedern. In meinem letzten Blog-Artikel habe ich Gründe genannt, warum schlechte Monolithen entstehen. Am Ende bin ich darauf eingegangen, dass Eric Evans bereits 2003 in seinem Buch „Domain-Driven Design – Tackling Complexity in the Heart of Software” darüber geschrieben hat, dass es bei großen Software-Systemen notwendig ist, diese in fachlich abgeschlossene Bereiche, sogenannte „Bounded Contexts“ zu unterteilen. Ich möchte jetzt in diesem Artikel zeigen, wie man mit DDD eine erste Idee für gute Bounded Contexts bekommen kann und so die Grundlage für eine wartbare, skalierbare und verständliche Softwarearchitekturlegt.
Darauf, wie man die gefundenen potenziellen Kontext-Grenzen im Detail überprüft und ggf. schärft, werde ich im dritten Teil dieser Blog-Serie eingehen.
Während der erste Teil des Buches von Eric Evans, der die modellgetriebene Entwicklung im engeren Sinne behandelt, viel Aufmerksamkeit erhielt, blieb der zweite Teil – das strategische Design – lange Zeitweitgehend unbeachtet. Dabei enthält gerade dieser Abschnitt viele Konzepte, die heute besonders relevant sind. Eric Evans zeigt hier, wie man große Systeme sinnvoll strukturiert: Systeme, die nicht mehr von einem einzelnen Team alleine entwickelt werden können und daher eine intensive Kommunikation zwischenmehreren Teams erfordern.
Bereits 2003 erkannte Evans, dass in großen Systemen kein einzelnes, einheitliches Modell alle fachlichen Anforderungen sinnvoll abbilden kann. Übrigens ein häufig in der SOA-Welt gemachter Fehler). Stattdessen empfiehlt er, komplexe Fachlichkeiten in kontextbezogene Teilmodelle, sogenannte Bounded Contexts, zu unterteilen. Jeder dieser Kontexte bildet einen unabhängigen Bereich, in dem Begriffe und Regeln konsistent angewendet werden. Die Interaktion zwischen den Kontexten erfolgt über klar definierte Schnittstellen – sei es durch APIs, Events oder Anti-Corruption Layer.
Die Idee von Bounded Contexts geht über ein reines Architekturpattern hinaus: Sie ist eine direkte Antwort auf das Problem, dass komplexe Systeme häufig an unklaren Verantwortlichkeiten und Begrifflichkeiten scheitern. Evans betont, dass Bounded Contexts entlang desgesamten Systems getrennt sein sollten – von den Teams über den Code bis hin zur Datenbank-Struktur – und dass die Beziehungen zwischen ihnen bewusst gestaltet werden müssen. Hierfür schlägt er explizite Patterns vor.
In der Praxis bedeutet die Trennung, dass niemals mehr als ein Team für einen Bounded Context verantwortlich sein darf. Dass ein Team mehrere Kontexte betreut, habe ich in Projekten schon erlebt und das führt auch selten zu Problemen.
Generell sind bei diesem Vorgehen die größten Herausforderungen fachliche Konflikte zwischen den Kontexten. Kommunizieren die Teams zweier Kontexte miteinander kann es zu Missverständnissen kommen, wenn in den beiden Kontexten z.B. derselbe Begriff für unterschiedliche Domänenkonzepte verwendet wird oder wenn der umgekehrte Fall vorliegt, nämlich dass dasselbe Domänenkonzept aus unterschiedlichen Sichten (nämlich jeweils aus der Kontext-Sicht) betrachtet wird und deshalb unterschiedlich benannt ist.
Was 2003 noch theoretisch wirkte, ist heute ein entscheidender Schritt, um Systeme nicht nur technisch, sondern entlangfachlicher Grenzen zu strukturieren – und so die Komplexität beherrschbar zumachen.
Erst mit dem Aufkommen von Microservice-Architekturen bekam das „Strategic Design“ aus dem Buch von Eric Evans die Aufmerksamkeit, die ihm gebührt, als klar wurde, dass sich mit den dort beschriebenen Patterns insbesondere Microservice-Architekturen gut schneiden lassen (um eine zeitliche Einschätzung zu bekommen: Ich selber hielt erst auf der Bed-Con 2015, also mehr als 10 Jahre nach Erscheinen des Buches einen Vortrag darüber, wie sich Microservices mit Domain-Driven Design gut schneiden lassen.
Domain-Driven Design erlebt seither seinen zweiten Frühling. Es wurden und werden Methodenentwickelt, wie sich gemeinsam mit allen Beteiligten die Fachlichkeit einer Domäne gut erarbeiten lässt.
Eine von uns immer wieder gerne und erfolgreich verwendete Methode ist das von Alberto Brandolini erfundene Event Storming Während andere Methoden wie z.B. das Domain-Storytelling häufig den Benutzer in den Mittelpunkt stellen (was je nach Zielsetzung auch sinnvoll ist), zeichnet das Event Storming aus, dass das Software-System im Fokus steht. Daher ist es meiner Meinung nach besonders gutgeeignet, aus dem Ergebnis später Bounded-Context-Grenzen zu ermitteln.
Das Buch über Event Storming, das Alberto Brandolini auf Lean Pub veröffentlicht hat, ist zwar noch nicht ganz fertig gestellt. Der erste Teil über das Big-Picture-Event-Storming und Process-Modelling liefert aber schon gute Anstöße und Ideen, um potenzielle Kontext-Grenzen zu identifizieren.
Da der hintere Teil des Buches, in dem es konkret darum gehen soll, Kontextgrenzen zu identifizieren, leider noch nicht fertig ist, werde ich hier stattdessen aus unserer eigenen Erfahrung berichten, wie es gelingen kann auf Basis von Event-Storming-Workshops einen sinnvollen Service-Schnitt zu ermitteln.
Zunächst gilt es, einen guten Überblick über die Fachlichkeit zu bekommen. Dabei ist einerseits das Ziel, in einzelne Details nicht zu tief einzutauchen, aber andererseits doch so detailliert zu werden, dass das Ergebnis als Grundlage für weitere Schritte verwendet werden kann.
Gut geeignet ist dafür das Big-Picture-Event-Storming .
Das Big-Picture-Event Storming ist ein kollaboratives Workshop-Format, das auf die zentrale Idee von Alberto Brandolini setzt: „Merge the People, split the Software“
Statt einzelne Analysten oder Entwickler in die Interpretation des Ist-Zustands zu schicken, bringt das Big-Picture-Event-Storming alle relevanten Stakeholder für einen Tag zusammen – Fachbereiche, Entwickler, Tester, Produktverantwortliche.
Der erste Schritt ist dabei ein Brainstorming, bei dem jeder für sich alle (aus seiner Sicht) fachlich relevanten Ereignisse(„Events“) auf orangene Zettel schreibt, die dann im Anschluss gemeinsam an der Wand, bzw. auf einem Brown Paper in eine zeitliche Reihenfolge gebracht werden.
Die Idee, in diesem ersten Schritt Events und nicht etwa Aktionen (Commands) zu verwenden, wirkt insbesondere für Fachexperten häufig zunächst befremdlich, erweist sich in der Praxis aber als äußerst geschickt, weil Events Tatsachen beschreiben wie, „Bestellung wurde aufgegeben“, „Zahlung wurde verbucht“, usw.
Sie beschreiben vergangene, beobachtbare Geschäftsvorfälle, die nicht mehr bestritten werden können. Commands hingegen drücken Absichten aus („Kundewill bestellen“), deren Ausführung abhängig von Geschäftsregeln ist. Das führt schnell zu Diskussionen über Berechtigungen, Validierungen oder Implementierung– und genau das will man im Big Picture noch vermeiden. Dadurch, dass Events faktenbasiert sind, eignen sie sich ideal als gemeinsamer Ausgangspunkt, um die Fachlichkeit zu diskutieren.
Wenn es uns darum geht, das System besser zu verstehen und einen optimalen Modulschnitt zubekommen, ist auf Basis des Ergebnisses des Big-Picture-Event-Stormings ein Process Modelling Workshop sinnvoll.
Ein Missverständnis, auf das wir häufig treffen, wenn sich Unternehmen bereits mit Event Storming auseinandergesetzt haben, ist, dass das Process Modelling direkt im Anschluss am gesamten Big Picture und auch mit derselben Gruppe durchgeführt wird, mit der auch das Big Picture Event Storming stattgefunden hat.
In der Praxis hat sich das aber als wenig sinnvoll erwiesen. Das Process Modelling geht viel mehr in technische Details, bei der Fachabteilungen schnell abgehängt sind und auch keinen Mehrwert bieten können. Auch beim Umfang lohnt es sich, zunächst einen Ausschnitt aus dem Big-Picture-Event-Storming zu nehmen und diesen mittels Process-Modelling konkreter zu modellieren.
Auch wenn die Fachexperten bei einem Process-Modelling-Workshop nicht durchgehend beteiligt sein müssen, ist es sinnvoll, dass sie nicht weit entfernt sind, um sie punktuell hinzuziehen zu können, falls sich im Laufe des Prozesses Unklarheiten oder Fragen ergeben.
Das Process-Modelling ist insbesondere an Kontext-Grenzen wertvoll. Da diese ja aber noch nicht bekannt sind, werden Heuristiken benötigt, um mögliche Kontext-Grenzen zu identifizieren, an denen dann ein Process-Modelling durchgeführt werden kann.
Mögliche Heuristiken beschreibt Alberto Brandolini in seinem Buch:
Eine davon sind Pivotal Events, das sind Zeitpunkte (bzw. Events) ab denen ein neuer Prozess-Abschnitt beginnt. Die Reihenfolge von Events zwischen zwei Pivotal Events ist häufig beliebig änderbar, Events über ein Pivotal Event hinweg zu tauschen, ist aber nicht sinnvoll. Ein klassisches Beispiel aus einem Onlineshop wären die Events, die den Warenkorb verändern, also z.B. „Artikel in den Warenkorb gelegt“, „Artikelmenge geändert“, „Artikel aus dem Warenkorbentfernt“. Diese können in beliebiger Reihenfolge stattfinden, bis das Event „Checkout gestartet“ stattfindet. Letzteres ist also ein Pivotal Event, deutet also auf einen Kontext-Wechsel hin. Von da ab können wieder andere Events in beliebiger Reihenfolge stattfinden wie „Zahlart ausgewählt“, „Rechnungsadresse festgelegt“, „Lieferadresse festgelegt“ bis das nächste Pivotal-Event „Bestellung abgeschickt“ stattfindet.
Im Big-Picture-Event-Storming lassen sich solche Stellen gut visuell markieren, z. B. mit Kreppband, weil sie auch beim Sortieren der Events helfen. Beim Process Modelling können Pivotal Events als Ausgangspunkt dienen.
Weitere Heuristiken sind Wortkonflikte. Stellt man beim Big-Picture-Event-Storming fest, dass von unterschiedlichen Teilnehmern unterschiedliche Begriffe für das gleiche Objekt (z. B. Produkt, Artikel, Ware)verwendet werden, weist das entweder auf ein fehlendes gemeinsames Verständnishin - man sollte sich dann auf einen Begriff einigen und diesen in einem Glossar festhalten – oder es weist auf unterschiedliche fachliche Perspektivenhin. Manchmal meinen Beteiligte tatsächlich verschiedene Dinge: Die Lagerlogistik spricht von Kisten, der Produktmanager von Vermarktungseinheiten. Hier helfen Diskussionen nicht nur zur Verständigung, sondern auch beim Finden von Kontextgrenzen.
Eine weitere mögliche Heuristik sind die tatsächlichen Use Cases. Um möglichst wenig Kommunikation zwischen Kontexten zu haben, wäre es sinnvoll, wenn ein Use Case innerhalb eines Kontextes abgehandelt werden könnte. Indikator dafür könnte sein, welche Person eine Reihe von Eventsausführt. Die ausführende Person („People“) kann man im Big-Picture Event Storming als kleine gelbe Zettel an die Events hängen, um daraus spätermögliche Kontexte abzuleiten.
Die beschriebenen Heuristiken sind, wie der Name schon sagt, nur Heuristiken. Als einziges Kriterium für Bounded Contexte reichen sie nicht. Ein weiterer entscheidender Punkt sind die Datenflüsse. Wo entstehen welche Daten, wer benötigt sie, welche Datenflüsse haben wir also?
Die Datenflüsse analysieren wir in der Regel mit einer Kombination aus Process Modelling und Software Design, bei dem wir die Aggregates identifizieren. Auf dieses Vorgehen gehe ich im nächsten Teil dieser Blog-Serie ein.
Die Identifikation guter Bounded Contexts ist ein zentraler Schritt, um komplexe Systeme beherrschbar zu machen. Wie gezeigt, liefert das Big-Picture-Event-Storming die Grundlage, um Prozesse und Fachlichkeit zu verstehen. Ein darauf aufbauender Process Modelling Workshoperlaubt es, die Fachlichkeit in konkrete Abläufe zu übersetzen und erste Ansatzpunkte für Kontextgrenzen zu erkennen.
Heuristiken wie Pivotal Events, Wortkonflikte oder Use Cases helfen dabei, mögliche Kontextgrenzen zu identifizieren, während die Analyse der Datenflüsse sicherstellt, dass die Abgrenzung auch technisch sinnvoll ist. Wichtig ist, dass diese Methoden nur Anhaltspunkte liefern: Das Finden von Bounded Contexts bleibt ein iterativer, fachlich getriebener Prozess, bei dem Kommunikation zwischen Teams und Fachbereichen entscheidend ist.
Wer diese Schritte konsequent verfolgt, legt die Basis für eine modulare, wartbare Architektur, in der Fachlichkeit klar abgebildet, Abhängigkeiten reduziert und Änderungen kontrolliert umgesetzt werden können.
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 sicher zu sein, den richtigen Service-Schnitt gefunden zu haben. Darauf, wie man das tun kann, gehe ich wie geschrieben im nächsten Blog-Artikel ein.
Genau hier setzt Domain-Driven Design(DDD) an: Es bietet einen strukturierten Ansatz, um fachliche Zusammenhänge zu verstehen und die Software in klar abgegrenzte Bounded Contexts zu gliedern. In meinem letzten Blog-Artikel habe ich Gründe genannt, warum schlechte Monolithen entstehen. Am Ende bin ich darauf eingegangen, dass Eric Evans bereits 2003 in seinem Buch „Domain-Driven Design – Tackling Complexity in the Heart of Software” darüber geschrieben hat, dass es bei großen Software-Systemen notwendig ist, diese in fachlich abgeschlossene Bereiche, sogenannte „Bounded Contexts“ zu unterteilen. Ich möchte jetzt in diesem Artikel zeigen, wie man mit DDD eine erste Idee für gute Bounded Contexts bekommen kann und so die Grundlage für eine wartbare, skalierbare und verständliche Softwarearchitekturlegt.
Darauf, wie man die gefundenen potenziellen Kontext-Grenzen im Detail überprüft und ggf. schärft, werde ich im dritten Teil dieser Blog-Serie eingehen.
Während der erste Teil des Buches von Eric Evans, der die modellgetriebene Entwicklung im engeren Sinne behandelt, viel Aufmerksamkeit erhielt, blieb der zweite Teil – das strategische Design – lange Zeitweitgehend unbeachtet. Dabei enthält gerade dieser Abschnitt viele Konzepte, die heute besonders relevant sind. Eric Evans zeigt hier, wie man große Systeme sinnvoll strukturiert: Systeme, die nicht mehr von einem einzelnen Team alleine entwickelt werden können und daher eine intensive Kommunikation zwischenmehreren Teams erfordern.
Bereits 2003 erkannte Evans, dass in großen Systemen kein einzelnes, einheitliches Modell alle fachlichen Anforderungen sinnvoll abbilden kann. Übrigens ein häufig in der SOA-Welt gemachter Fehler). Stattdessen empfiehlt er, komplexe Fachlichkeiten in kontextbezogene Teilmodelle, sogenannte Bounded Contexts, zu unterteilen. Jeder dieser Kontexte bildet einen unabhängigen Bereich, in dem Begriffe und Regeln konsistent angewendet werden. Die Interaktion zwischen den Kontexten erfolgt über klar definierte Schnittstellen – sei es durch APIs, Events oder Anti-Corruption Layer.
Die Idee von Bounded Contexts geht über ein reines Architekturpattern hinaus: Sie ist eine direkte Antwort auf das Problem, dass komplexe Systeme häufig an unklaren Verantwortlichkeiten und Begrifflichkeiten scheitern. Evans betont, dass Bounded Contexts entlang desgesamten Systems getrennt sein sollten – von den Teams über den Code bis hin zur Datenbank-Struktur – und dass die Beziehungen zwischen ihnen bewusst gestaltet werden müssen. Hierfür schlägt er explizite Patterns vor.
In der Praxis bedeutet die Trennung, dass niemals mehr als ein Team für einen Bounded Context verantwortlich sein darf. Dass ein Team mehrere Kontexte betreut, habe ich in Projekten schon erlebt und das führt auch selten zu Problemen.
Generell sind bei diesem Vorgehen die größten Herausforderungen fachliche Konflikte zwischen den Kontexten. Kommunizieren die Teams zweier Kontexte miteinander kann es zu Missverständnissen kommen, wenn in den beiden Kontexten z.B. derselbe Begriff für unterschiedliche Domänenkonzepte verwendet wird oder wenn der umgekehrte Fall vorliegt, nämlich dass dasselbe Domänenkonzept aus unterschiedlichen Sichten (nämlich jeweils aus der Kontext-Sicht) betrachtet wird und deshalb unterschiedlich benannt ist.
Was 2003 noch theoretisch wirkte, ist heute ein entscheidender Schritt, um Systeme nicht nur technisch, sondern entlangfachlicher Grenzen zu strukturieren – und so die Komplexität beherrschbar zumachen.
Erst mit dem Aufkommen von Microservice-Architekturen bekam das „Strategic Design“ aus dem Buch von Eric Evans die Aufmerksamkeit, die ihm gebührt, als klar wurde, dass sich mit den dort beschriebenen Patterns insbesondere Microservice-Architekturen gut schneiden lassen (um eine zeitliche Einschätzung zu bekommen: Ich selber hielt erst auf der Bed-Con 2015, also mehr als 10 Jahre nach Erscheinen des Buches einen Vortrag darüber, wie sich Microservices mit Domain-Driven Design gut schneiden lassen.
Domain-Driven Design erlebt seither seinen zweiten Frühling. Es wurden und werden Methodenentwickelt, wie sich gemeinsam mit allen Beteiligten die Fachlichkeit einer Domäne gut erarbeiten lässt.
Eine von uns immer wieder gerne und erfolgreich verwendete Methode ist das von Alberto Brandolini erfundene Event Storming Während andere Methoden wie z.B. das Domain-Storytelling häufig den Benutzer in den Mittelpunkt stellen (was je nach Zielsetzung auch sinnvoll ist), zeichnet das Event Storming aus, dass das Software-System im Fokus steht. Daher ist es meiner Meinung nach besonders gutgeeignet, aus dem Ergebnis später Bounded-Context-Grenzen zu ermitteln.
Das Buch über Event Storming, das Alberto Brandolini auf Lean Pub veröffentlicht hat, ist zwar noch nicht ganz fertig gestellt. Der erste Teil über das Big-Picture-Event-Storming und Process-Modelling liefert aber schon gute Anstöße und Ideen, um potenzielle Kontext-Grenzen zu identifizieren.
Da der hintere Teil des Buches, in dem es konkret darum gehen soll, Kontextgrenzen zu identifizieren, leider noch nicht fertig ist, werde ich hier stattdessen aus unserer eigenen Erfahrung berichten, wie es gelingen kann auf Basis von Event-Storming-Workshops einen sinnvollen Service-Schnitt zu ermitteln.
Zunächst gilt es, einen guten Überblick über die Fachlichkeit zu bekommen. Dabei ist einerseits das Ziel, in einzelne Details nicht zu tief einzutauchen, aber andererseits doch so detailliert zu werden, dass das Ergebnis als Grundlage für weitere Schritte verwendet werden kann.
Gut geeignet ist dafür das Big-Picture-Event-Storming .
Das Big-Picture-Event Storming ist ein kollaboratives Workshop-Format, das auf die zentrale Idee von Alberto Brandolini setzt: „Merge the People, split the Software“
Statt einzelne Analysten oder Entwickler in die Interpretation des Ist-Zustands zu schicken, bringt das Big-Picture-Event-Storming alle relevanten Stakeholder für einen Tag zusammen – Fachbereiche, Entwickler, Tester, Produktverantwortliche.
Der erste Schritt ist dabei ein Brainstorming, bei dem jeder für sich alle (aus seiner Sicht) fachlich relevanten Ereignisse(„Events“) auf orangene Zettel schreibt, die dann im Anschluss gemeinsam an der Wand, bzw. auf einem Brown Paper in eine zeitliche Reihenfolge gebracht werden.
Die Idee, in diesem ersten Schritt Events und nicht etwa Aktionen (Commands) zu verwenden, wirkt insbesondere für Fachexperten häufig zunächst befremdlich, erweist sich in der Praxis aber als äußerst geschickt, weil Events Tatsachen beschreiben wie, „Bestellung wurde aufgegeben“, „Zahlung wurde verbucht“, usw.
Sie beschreiben vergangene, beobachtbare Geschäftsvorfälle, die nicht mehr bestritten werden können. Commands hingegen drücken Absichten aus („Kundewill bestellen“), deren Ausführung abhängig von Geschäftsregeln ist. Das führt schnell zu Diskussionen über Berechtigungen, Validierungen oder Implementierung– und genau das will man im Big Picture noch vermeiden. Dadurch, dass Events faktenbasiert sind, eignen sie sich ideal als gemeinsamer Ausgangspunkt, um die Fachlichkeit zu diskutieren.
Wenn es uns darum geht, das System besser zu verstehen und einen optimalen Modulschnitt zubekommen, ist auf Basis des Ergebnisses des Big-Picture-Event-Stormings ein Process Modelling Workshop sinnvoll.
Ein Missverständnis, auf das wir häufig treffen, wenn sich Unternehmen bereits mit Event Storming auseinandergesetzt haben, ist, dass das Process Modelling direkt im Anschluss am gesamten Big Picture und auch mit derselben Gruppe durchgeführt wird, mit der auch das Big Picture Event Storming stattgefunden hat.
In der Praxis hat sich das aber als wenig sinnvoll erwiesen. Das Process Modelling geht viel mehr in technische Details, bei der Fachabteilungen schnell abgehängt sind und auch keinen Mehrwert bieten können. Auch beim Umfang lohnt es sich, zunächst einen Ausschnitt aus dem Big-Picture-Event-Storming zu nehmen und diesen mittels Process-Modelling konkreter zu modellieren.
Auch wenn die Fachexperten bei einem Process-Modelling-Workshop nicht durchgehend beteiligt sein müssen, ist es sinnvoll, dass sie nicht weit entfernt sind, um sie punktuell hinzuziehen zu können, falls sich im Laufe des Prozesses Unklarheiten oder Fragen ergeben.
Das Process-Modelling ist insbesondere an Kontext-Grenzen wertvoll. Da diese ja aber noch nicht bekannt sind, werden Heuristiken benötigt, um mögliche Kontext-Grenzen zu identifizieren, an denen dann ein Process-Modelling durchgeführt werden kann.
Mögliche Heuristiken beschreibt Alberto Brandolini in seinem Buch:
Eine davon sind Pivotal Events, das sind Zeitpunkte (bzw. Events) ab denen ein neuer Prozess-Abschnitt beginnt. Die Reihenfolge von Events zwischen zwei Pivotal Events ist häufig beliebig änderbar, Events über ein Pivotal Event hinweg zu tauschen, ist aber nicht sinnvoll. Ein klassisches Beispiel aus einem Onlineshop wären die Events, die den Warenkorb verändern, also z.B. „Artikel in den Warenkorb gelegt“, „Artikelmenge geändert“, „Artikel aus dem Warenkorbentfernt“. Diese können in beliebiger Reihenfolge stattfinden, bis das Event „Checkout gestartet“ stattfindet. Letzteres ist also ein Pivotal Event, deutet also auf einen Kontext-Wechsel hin. Von da ab können wieder andere Events in beliebiger Reihenfolge stattfinden wie „Zahlart ausgewählt“, „Rechnungsadresse festgelegt“, „Lieferadresse festgelegt“ bis das nächste Pivotal-Event „Bestellung abgeschickt“ stattfindet.
Im Big-Picture-Event-Storming lassen sich solche Stellen gut visuell markieren, z. B. mit Kreppband, weil sie auch beim Sortieren der Events helfen. Beim Process Modelling können Pivotal Events als Ausgangspunkt dienen.
Weitere Heuristiken sind Wortkonflikte. Stellt man beim Big-Picture-Event-Storming fest, dass von unterschiedlichen Teilnehmern unterschiedliche Begriffe für das gleiche Objekt (z. B. Produkt, Artikel, Ware)verwendet werden, weist das entweder auf ein fehlendes gemeinsames Verständnishin - man sollte sich dann auf einen Begriff einigen und diesen in einem Glossar festhalten – oder es weist auf unterschiedliche fachliche Perspektivenhin. Manchmal meinen Beteiligte tatsächlich verschiedene Dinge: Die Lagerlogistik spricht von Kisten, der Produktmanager von Vermarktungseinheiten. Hier helfen Diskussionen nicht nur zur Verständigung, sondern auch beim Finden von Kontextgrenzen.
Eine weitere mögliche Heuristik sind die tatsächlichen Use Cases. Um möglichst wenig Kommunikation zwischen Kontexten zu haben, wäre es sinnvoll, wenn ein Use Case innerhalb eines Kontextes abgehandelt werden könnte. Indikator dafür könnte sein, welche Person eine Reihe von Eventsausführt. Die ausführende Person („People“) kann man im Big-Picture Event Storming als kleine gelbe Zettel an die Events hängen, um daraus spätermögliche Kontexte abzuleiten.
Die beschriebenen Heuristiken sind, wie der Name schon sagt, nur Heuristiken. Als einziges Kriterium für Bounded Contexte reichen sie nicht. Ein weiterer entscheidender Punkt sind die Datenflüsse. Wo entstehen welche Daten, wer benötigt sie, welche Datenflüsse haben wir also?
Die Datenflüsse analysieren wir in der Regel mit einer Kombination aus Process Modelling und Software Design, bei dem wir die Aggregates identifizieren. Auf dieses Vorgehen gehe ich im nächsten Teil dieser Blog-Serie ein.
Die Identifikation guter Bounded Contexts ist ein zentraler Schritt, um komplexe Systeme beherrschbar zu machen. Wie gezeigt, liefert das Big-Picture-Event-Storming die Grundlage, um Prozesse und Fachlichkeit zu verstehen. Ein darauf aufbauender Process Modelling Workshoperlaubt es, die Fachlichkeit in konkrete Abläufe zu übersetzen und erste Ansatzpunkte für Kontextgrenzen zu erkennen.
Heuristiken wie Pivotal Events, Wortkonflikte oder Use Cases helfen dabei, mögliche Kontextgrenzen zu identifizieren, während die Analyse der Datenflüsse sicherstellt, dass die Abgrenzung auch technisch sinnvoll ist. Wichtig ist, dass diese Methoden nur Anhaltspunkte liefern: Das Finden von Bounded Contexts bleibt ein iterativer, fachlich getriebener Prozess, bei dem Kommunikation zwischen Teams und Fachbereichen entscheidend ist.
Wer diese Schritte konsequent verfolgt, legt die Basis für eine modulare, wartbare Architektur, in der Fachlichkeit klar abgebildet, Abhängigkeiten reduziert und Änderungen kontrolliert umgesetzt werden können.
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 sicher zu sein, den richtigen Service-Schnitt gefunden zu haben. Darauf, wie man das tun kann, gehe ich wie geschrieben im nächsten Blog-Artikel ein.
