Als alter Hase im Geschäft der Software Entwicklung ist mir Domain Driven Design schon lange bekannt. Schließlich hat Eric Evans schon im Buch „Domain Driven Design: Tackling Complexity in the Heart of Software“ 2003 darüber geschrieben . Außerdem hat er erst kürzlich erwähnt, dass Domain Driven Design „not done“ ist und sich permanent weiterentwickelt. 

Gerade erlebe ich selbst eine Renaissance des Themas vor allem über Collaborative Modelling Methoden, die ich über das CoMo Camp kennenlernen durfte. Zuallererst dachte ich als alter Skeptiker, ok, kenn ich schon, doch als ich begonnen habe CoMo Methoden immer mehr zu verwenden, habe ich verstanden, dass es nicht nur “alter Wein in neuen Schläuchen” ist sondern eine ToolBox die relevanter denn je wird, je komplexer unsere Welt wird.

Ich versuche hier einen kurzen Abriss darüber zu geben, warum wir gerade heute uns mit DDD beschäftigen sollten und welche Methoden ich besonders stark in Kundensettings erlebt habe.

Warum DDD gerade jetzt?

Die Software Welt wird immer faszinierender, gerade mit AI unterstützen Dev Environments und Cloud Umgebungen, die ein enormes Skalieren zulassen. Meistens befinde ich mich jedoch im Umfeld meiner Kunden in einer Zwickmühle zwischen bestehenden Legacy Systemen und dem Wunsch „state-of-the-art“ zu sein und den coolen „neuen Scheiß“ zu machen.

Schlussendlich geht es oft um beinharte Financials, unser „Cost of Change“ in der IT wird höher, neue oder auch nicht mehr ganz so neue Buzzwords wie „Micro Services“, „Cloud native“, etc. versprechen die schöne neue Welt, die die großen Beratungsfirmen auch in tollen Strategie-Papieren ausarbeiten. 

Doch wie starten wir? Wo fangen wir an? Daran scheitert es dann oft, weil die Kosten enorm erscheinen und der erste kleine Schritt nicht greifbar ist. 

Wir müssen die Domäne unseres Business verstehen und diese auch klar beschreiben können. Die IT und Software Entwicklung ist integraler Bestandteil des Business, ermöglicht auch neue Geschäftsbereiche aufzumachen und wird trotzdem leider viel zu oft noch als reine Kostenstelle oder „Lieferstraße“ gesehen, die wie eine Fabrik unsere Wünsche erfüllt. 

Hier beginnt die Magie von DDD, denn zuallererst ist es nie ein technisches Thema, sondern ein fachliches, das wir verstehen müssen. Welche Probleme lösen wir eigentlich für wen?

Dazu dient uns die sogenannte „Ubiquituous Language“, also eine gemeinsame Sprache aller Stakeholder um Missverständnisse zu vermeiden und klar kommunizieren zu können.

Der nächste Schritt ist, dass wir strategisch auf Augenhöhe kommunizieren und ein gemeinsames Bild schaffen.

Wir brauchen also Mittel um die komplexe Welt für den Menschen wieder greifbar zu machen und auch Methoden um große komplexe Dinge in kleine verständliche zu zerlegen. Und im Idealfall entsprechen diese fachlichen Kontexte gleichzeitig auch den technischen („Bounded Context“). 

Wo startet man und welche Probleme löst man damit?

Schon das Agile Manifest sagt „Business people and developers must work together daily throughout the project.“ Also selbst 2001 haben die mittlerweile alle grauhaarigen und leider ausschließlich Herren erkannt, dass Business und IT eng kollaborieren müssen und auch der Volksmund weiß „durchs Reden kommen die Leit zam“. Und ja, so banal es vielleicht klingen mag, es stimmt nach wie vor. 

Auch in unserer hochdigitalen Welt und Zeit der remote Kollaboration sind vor Ort durchgeführte Workshops mit den richtigen Leuten immer noch das effektivste Mittel um komplexe Problemstellungen zu behandeln.

Ich verwende jetzt ein Beispiel um die Schritte zu erklären, wie man ganz konkret so ein Thema mit DDD und CoMo angehen kann.

Beispiel-Anwendungsfall: Die Systemeffizienz steigern

Wir befinden uns in einer größeren Firma, die verschiedene Systeme hat um Förderprogramme abzuwickeln, also öffentliche Gelder, die in unterschiedlichsten Fällen Leuten oder auch ganzen Unternehmen ausgezahlt werden. 

Hier geht es jetzt darum die „digitale Effizienz“ zu steigern.

Wie können wir jetzt rasch die Fachdomäne verstehen um dann darüber zu legen was wir optimieren können?

Big Picture Event Storming

Alberto Brandolini, selbst Teilnehmer des CoMo Camp hat eine der wesentlichen Methoden beschrieben, die hier zum Einsatz kommen: Event Storming (https://www.eventstorming.com)

Im Prinzip geht es darum einen Prozess von vorne bis hinten gemeinsam zu modellieren. Es ist also wichtig, die richtigen Stakeholder aus Business und IT im Raum zu haben um gemeinsam ein vollständiges Bild mittels Post-Ist an der Wand zu visualisieren und die gesamte „Geschichte“ gemeinsam zu erzählen.

Beim Big Picture geht es einmal darum, das Business grob zu modellieren, um eine Gesamtübersicht zu haben und eine gemeinsame Sprache bei allen Beteiligten zu schaffen. 

Bewährt hat sich als Übung mit dem Märchen Cinderella zu starten:

Abbildung 1 Cinderella Event Storming, Quelle: https://leanpub.com/eventstorming_handbook

Am Beispiel sieht man ungefähr wie das aufgebaut ist, man erhält „Events“ die in der Vergangenheit geschrieben werden und arbeitet sich dann an einer möglichst großen Fläche von dort weg nach links (früheres Event) oder nach rechts (später), bis man das Gefühl hat es ist alles drauf.

Bei unserem Beispiel Anwendungsfall mit den Förderungen hat sich mit 20 Teilnehmer:Innen nach ca 2h ein Bild mit über 400 Post-Its ergeben und Aussagen wie „unsere Domäne ist doch komplexer als ich gedacht habe“ und „jetzt verstehe ich erst, was überall passiert“ zeigen schon alleine den Mehrwert für die Beteiligten so eine Session zu machen.

Pivotal Events finden

Wir haben jetzt ein Bild und möchten das Verständnis weiter schärfen, dazu versuchen wir kritische Events in unserer „Story“ zu finden. Bei Cinderella wäre das zB: Father died, oder „lost shoe“. Diese zeigen uns wo es fachliche Grenzen gibt.

Im Förderfall war das zum Beispiel der Übergang von einer Definition der Förderung in die Antragstellung, also die Phase, bei der die Förderung bereits aktiv war und Leute Förderanträge stellen konnten, dann in weiterer Folge auch die Förder-Genehmigung, Auszahlung, etc.

Jetzt konnten wir auch die technischen Systeme dazu legen und haben bereits gesehen, dass sich hier technologie und Fachdomäne nicht ganz decken bzw überschneiden.

Domänen und Sub-Domänen identifizieren

So, wie hilft uns jetzt diese riesige Informationsquelle?

Wir konnten jetzt Anfangen die fachlichen Domänen im Sinne von DDD genau zu bezeichnen und auch abzugrenzen.

Eine Domäne ist ein spezifischer Geschäftsbereich, der eine bestimmte Geschäftslogik und Fachlichkeit umfasst, welche für die Erreichung der Unternehmensziele wesentlich ist. Subdomänen sind Unterbereiche innerhalb dieser Domäne, die jeweils spezifische Aspekte dieser Fachlichkeit detaillierter behandeln. Diese Einteilung ermöglicht es, große und komplexe Systeme in kleinere, handhabbare Teile zu zerlegen, die leichter zu verstehen und zu managen sind.

In unserem Fall waren die Domänen:

• Abstimmung der Förderung
• Beantragung (der Förderung)
• Auswahl 
• Vergabe
• Auszahlung
• Abschluss

Hier gab es dann weitere Unter-Domänen aber der Vorteil war sofort, dass eine klare Sprache geschaffen wurde, um zu beschreiben welchen Teil man im System meint. Es wurde auch noch deutlicher herausgearbeitet, dass sich die Fachdomäne unterscheidet in kleinere Förderungen und größere Förderungen (mit Millionen-Summen pro Förderung). Hier lagen auch zwei unterschiedliche Systeme dahinter.

Wie geht’s es jetzt weiter?

Wir konnten durch die klare Modellierung der Domäne sehr klar auch feststellen wo im Fachprozess derzeit Probleme sind und wo zum Beispiel eine End-2-End digitale Journey noch nicht gegeben ist.

Somit wurde das erste System zur Ablöse identifiziert und auch klargestellt, welchen Bereich der Domäne das neue System umfassen soll. 

Um dann weiter ins Detail zu gehen können wir für spezifische Bereiche nochmal ein genaueres Event Storming machen oder zum Beispiel mit „Domain Story Telling“ die Story vom Business noch besser verstehen.

Wir können also bessere Entscheidungen treffen, die nicht nur heißen: Löse legacy System A durch ein neues System B ab, das genau das gleiche kann, sondern können das System spezifischer fachlich abgegrenzt bauen, was uns auch eine schöner abgegrenzte Architektur ermöglicht.

Fazit

Für mich klingen DDD und CoMo im ersten Schritt sehr abstrakt, jedoch nach der ersten Anwendung solcher Methoden findet man aus meiner Sicht sofort den konkreten Mehrwert und es ermöglicht sowohl Business als auch Technik klar darüber zu sprechen, was man lösen möchte und warum.

Ich kann daher jedem nur empfehlen, diese Methoden und auch den Weg in die Software Architektur mit Event Modelling, Bounded Context Definitionen genau anzusehen um nach wie vor eine Chance zu haben die moderne komplexe Welt zu meistern. Schlussendlich geht es immer noch um die Menschen dahinter und darum, coole Produkte mit Software zu machen, die Impact erzeugen.