entwickler.de: Was interessiert dich an Event Storming persönlich besonders?

Arne Limburg: Eine Kernidee von Domain-driven Design ist es, die Fachabteilung und die Entwicklung zusammenzubringen. Event Storming ist eine Methode, um diesen Prozess zu formalisieren. Aber Event Storming geht darüber hinaus. Wenn man es geschickt anstellt, kann man aus den Ergebnissen des Event Stormings sinnvolle Bounded Contexts ermitteln.

Wenn die Fachabteilung mit der Entwicklung spricht, ist es immer eine Herausforderung, dasselbe Abstraktionslevel zu finden.

entwickler.de: Kannst du einmal anhand eines Beispiels aus der Praxis erläutern, wie Event Storming funktioniert?

Arne Limburg: Wenn die Fachabteilung mit der Entwicklung spricht, ist es immer eine Herausforderung, dasselbe Abstraktionslevel zu finden. Indem man sich zuerst auf die fachlichen Events fokussiert, nähert man sich von der Ebene der Fachabteilung aus an. Unter Events wie „Produkt in den Warenkorb gelegt“, „Lieferadresse festgelegt“ kann sich jeder etwas vorstellen.

Im zweiten Schritt werden dann die Aktionen (Commands) gefunden, die die Events auslösen. Auch hierbei ist jedem schnell klar, was das ist. Entgegen der landläufigen Meinung, dass jedes Event durch ein eindeutiges Command ausgelöst wird, gibt es auch häufig die Situation, dass ein Event durch unterschiedliche Commands ausgelöst werden kann. „Lieferadresse festgelegt“ kann z.B. durch „Lieferadresse eingeben“, „Lieferadresse aus Liste wählen“ oder „Standardlieferadresse bestätigen“ ausgelöst werden.

Ein Modul ist nicht unabhängig, wenn es Datenbank-Tabellen verwendet, die Foreign-Key-Beziehungen in andere Bounded Contexts haben.

entwickler.de: Wenn man sich die Fachlichkeit und die Bounded Contexts gemeinsam erarbeitet hat: Wie implementiert man diese nun in Software? Welche Möglichkeiten gibt es da?

Arne Limburg: Eine wichtige Eigenschaft von Bounded Contexts ist, dass jeder durch genau ein Team betreut wird. Deshalb sollten die einzelnen Bounded Contexts auch sauber voneinander getrennt werden, um unabhängig zu sein. Das kann entweder dadurch passieren, dass jeder Bounded Context ein eigener Microservice ist. Oder, wenn man sich in einer monolithischen Applikation befindet, dass jeder Bounded Context ein eigenes Modul ist. Dieses sollte dann aber nach Möglichkeit wenig Code mit den anderen Bounded Contexts teilen.

Außerdem sollte darauf geachtet werden, dass die Trennung auch bis zur Datenbank durchgezogen wird. Ein Modul ist nicht unabhängig, wenn es Datenbank-Tabellen verwendet, die Foreign-Key-Beziehungen in andere Bounded Contexts haben.

entwickler.de: Vielen Dank für dieses Interview!