Java Magazin: 21 Jahre DDD, Zeit für ein zwischenzeitliches Resümee: Ist DDD in der „breiten Masse“ angekommen, oder bedarf es da noch des einen oder anderen Wegweisers?

Tobias Goeschel: Diese Frage ist nicht ganz einfach zu beantworten. Ganz sicher in der breiten Masse angekommen ist die Information, dass DDD bei der Planung und Umsetzung von Geschäftssoftwareprojekten hilfreich und für Microservices-Architekturen nahezu unverzichtbar ist. Also, das Bewusstsein ist da. Aber bei der Umsetzung gibt es noch viel Nachholbedarf: Derzeit sehe ich den weitaus größten Anteil der Unternehmen, gerade im Enterprise-Umfeld, entweder im Zustand „Das sollten wir unbedingt mal machen“ oder davon überzeugt, dass ein einzelner Workshop mit Erstellung eines Modells bereits einen fertigen, belastbaren Architekturentwurf liefert. Dass effektives DDD eine Umstellung des gesamten Vorgehens bei der Softwareentwicklung bedeutet, mit iterativer, interdisziplinärer Zusammenarbeit zwischen Entwicklungsteam und Fachbereich, ist für viele nicht greifbar.

Wenn DDD wirklich gut gemacht wird, werden Architekturentscheidungen häufig hinterfragt, schwierige Kontexte immer wieder neu diskutiert und durchaus auch mal ganze Module komplett neu programmiert. So etwas ist in klassischen Unternehmen politisch oft schwierig durchzusetzen oder wird durch gelebte Firmenkultur verhindert. Hinzu kommt, dass für die erfolgreiche Entwicklung mit DDD eine Vielzahl von anderen Skills, z. B. aus den Bereichen Software Crafting oder DevOps, benötigt werden. Die Einstiegshürde ist daher immer noch vergleichsweise hoch.

Am Ende also: jein. Wir sind noch lange nicht am Ende der Reise angekommen.

Stefan Hildebrandt: Es gibt mittlerweile recht viele Unternehmen, die auf DDD setzen, aber auch noch viele, die es nicht nutzen, und andere, die das Thema bisher noch nicht als Option für sich wahrgenommen haben. Auch die Arten der Adaptierung sind sehr unterschiedlich: Einige schneiden Systeme, Microservices oder Module nach Bounded Contexts, die im Vorfeld sauber erarbeitet wurden, verwenden nur noch Value-Objekte und leben ihre Fachlichkeit in ihrem System und ziehen großen Nutzen aus DDD. Andere packen Klassen aus unterschiedlichen Bereichen in Pakete mit den Namen domain, ports und adapter, nutzen nur Strings an allen externen Schnittstellen und nennen das dann hexagonale Architektur. Das ist dann vermutlich ein Rückschritt zum vorherigen Vorgehen. Hier ist sicher noch viel Aufklärungsarbeit und noch mehr praktische Erfahrung notwendig, damit alle einen Nutzen aus den Konzepten und dem bedarfsgerechten Einsatz der Werkzeuge von DDD ziehen können.

Stefan Hofer: Jedenfalls ist DDD über seinen ursprünglichen Anwendungsbereich hinausgewachsen: Es geht nicht mehr nur um Geschäftsanwendungen, die eine Organisation für sich selbst entwickelt. Mittlerweile wird DDD in der Entwicklung von Softwareprodukten für Unternehmen und private Nutzer eingesetzt. In diesen Bereichen werden wir noch viel Weiterentwicklung sehen. An (Fach-)Hochschulen ist DDD ebenfalls angekommen, das freut mich besonders.

Jörn Koch: DDD ist als Thema in den Köpfen der breiten Masse angekommen und wird nach meinem Eindruck vor allem als die Möglichkeit gesehen, Monolithen (aka „Big Ball of Mud“) zu vermeiden und stattdessen eine Landschaft von Standalone Systems aufzubauen.

Allerdings ist die breite Masse (noch) nicht in der Lage, DDD erfolgreich einzusetzen. Einige Missverständnisse, die das verhindern, sind typisch, z. B. dass eine dezentrale Datenhaltung nach DDD zu massiver Datenredundanz und zur Explosion der Datenmengen führen müsse. Solche Missverständnisse führen leider oft dazu, dass DDD nur inkonsequent eingesetzt wird (z. B. in Kombination mit einer zentralen Datenhaltung) und die mit DDD verknüpften Zielvorstellungen (z. B. zu einem guten Schnitt von Standalone Systems zu kommen) nicht erfüllt werden.

Neben den reinen DDD-Konzepten sind aus meiner Sicht pragmatische Methoden notwendig, die schrittweise zu DDD-konformen Ergebnissen hinleiten – trotz eines noch nicht „DDD-kompatiblen“ Mindsets bei den Beteiligten. Ein Beispiel sind szenariobasierte Methoden, in denen anhand von Beispielprozessen die fachlichen Grundlagen für einen DDD-Entwurf ermittelt werden.

Carola Lilienthal: Mein Eindruck ist, dass DDD in der breiten Masse als mögliche sinnvolle Methode angekommen ist. Das mache ich daran fest, dass es inzwischen auf allen Softwareentwicklungskonferenzen Vorträge zu DDD gibt. Wer sich also ein bisschen in unserer Disziplin umschaut, kommt am DDD nicht mehr vorbei. Der Einsatz von DDD in Projekten ist im Gegensatz dazu noch nicht wirklich verbreitet. Das liegt sicherlich daran, dass es schon sehr viel Software gibt, die anders entwickelt wurde, und auch daran, dass DDD bisher an den wenigsten Unis gelehrt wird. Es gibt also noch viel zu tun, um DDD für alle Softwareentwicklungsteams zugänglich zu machen.

Michael Plöd: Ich tue mich immer schwer, „die breite Masse“ zu definieren. Dafür ist die IT-Landschaft schlichtweg zu heterogen. Allerdings denke ich, dass Domain-Driven Design inzwischen ein Momentum erreicht hat, das definitiv nennenswert ist und das nun auch seit vielen Jahren eine gewisse Konstanz aufweist. Allerdings beobachte ich, dass Domain-Driven Design primär im Bereich der Softwareentwicklung und -architektur bekannt ist. Leider ist DDD in vielen Fachbereichen und bei zahlreichen Domain Experts noch kaum bis gar nicht bekannt. Hier denke ich, dass wir als Community ansetzen sollten um das Thema verstärkt in Richtung des Business zu tragen.

Nicole Rauch: Das hängt natürlich sehr davon ab, was man unter „angekommen“ versteht. Hat es die breite Masse schon mal gehört? Ja, definitiv. Weiß die Mehrheit, was das im Großen und Ganzen bedeutet? Da muss man vielleicht schon differenzieren. Ich glaube, dass viele ein gutes Verständnis der grundlegenden taktischen Patterns wie Entities und Value Objects haben oder auch, dass man seine Applikationen fachlich schneiden sollte, aber wenn es dann mehr in Richtung der konkreten Umsetzung dieser vielleicht etwas diffusen Vorstellungen geht, zum Beispiel dass die Domäne technikfrei sein muss (und dass das z. B. auch technische Annotationen betrifft) oder dass man die Domänensprache bis hinunter zur Datenbank benutzen muss (und ja, auch wenn es deutsche Begriffe sind!), da kann man schon manchmal in verwunderte Gesichter blicken.

Wenn man dann darauf schaut, wer DDD tatsächlich in der täglichen Arbeit einsetzt, wird es wirklich dünn.

Von daher würde ich sagen, die Theorie ist so weit schon einigermaßen angekommen, aber die praktische Anwendung bei weitem noch nicht.

Henning Schwentner: So dazwischen. Mittlerweile haben die meisten Entwicklerinnen und Entwickler die Abkürzung DDD zumindest schon mal gehört (auch dank des Microservices-Hypes); viele haben sich auch in der Theorie damit beschäftigt. In der Praxis wird DDD aber leider noch weniger breit eingesetzt, als das sinnvoll wäre. Oft höre ich da das Argument: „Das sind ja alles tolle Ideen, die beim Bau einer Software auf der grünen Wiese gut funktionieren, aber wir haben hier ja schon ein Altsystem.“ Als Wegweiser empfehle ich in solchen Fällen das gerade erscheinende Buch „Domain-Driven Transformation“ [1] von Carola Lilienthal und mir, das zeigt, wie man DDD auch nachträglich in ein existierendes Legacy-System einführt und dieses dadurch wieder handhabbar macht.

Eberhard Wolff: DDD ist schon lange in der breiten Masse angekommen – aber leider werden die meisten Ideen, wenn sie populär werden, verwässert oder falsch verstanden. Das hat es bei DDD gleich mehrfach gegeben: Am Anfang wurde DDD als ein Ansatz wahrgenommen, um objektorientierte Systeme auf Klasseneben zu designen. Mittlerweile ist den meisten klar, dass DDD auch Ansätze enthält, um eine grobgranulare Architektur zu definieren. Aber es gibt immer noch Missverständnisse: Zu oft wird ein klassisches Design genommen und die Elemente werden zu Bounded Context umdeklariert. So ändern sich zwar die Bezeichnungen, aber inhaltlich bleibt alles beim Alten.

JM: Hast du eine lustige oder interessante DDD-Geschichte, die du gerne mit der Community teilen willst?

Goeschel: Vor einigen Jahren habe ich in Helsinki für eine gemischte Gruppe aus 20 Personen ein Event-Storming-Training gehalten, das ich zuvor bereits etliche Male in Deutschland mit Kund:innen durchgeführt und eingespielt hatte. In meiner Beispieldomäne, einem Kinobetrieb mit Einkauf, Programmplanung, Filmauswahl und Ticketing, gab es einen Teilprozess, der das Kinoticket per E-Mail verschicken sollte, nachdem die Buchung angewiesen, aber bevor die Zahlung tatsächlich eingegangen war – ein Verfahren, das bei uns durchaus üblich ist; in der Regel gibt es ein Mahnwesen und Inkasso, das Säumnisse im Nachgang ahndet. In Finnland löste diese Idee ein wahre Empörungswelle aus: Ich bekam erklärt, dass die finnische Seele zwar freundlich und offen, aber „von Grund auf misstrauisch“ sei. So gäbe es keinesfalls – jemals – eine Transaktion, bei der die Ware vor dem Erhalt des Geldes ausgehändigt würde. Ebenso schwierig war es übrigens für mich, zu akzeptieren, dass mein eigenes Bild von der Domäne nicht korrekt war, was eine ganze Reihe von Änderungen für das Training nach sich zog.

Am Ende war es aber eine sehr erhellende Erfahrung: Nicht nur das reine Geschäft, sondern auch Landeskultur, Bräuche, Religion und ähnliche Einflüsse haben großen Anteil daran, wie Geschäftsprozesse modelliert und am Ende in Software gegossen werden. Auch deswegen empfiehlt es sich sogar für „altbekannte“ Domänen, die Vorstellungen in den Köpfen sichtbar zu machen und zu prüfen, ob sich die Annahmen der Beteiligten überschneiden.

Ironischerweise gab es übrigens beim anschließenden Besuch in der Bar um die Ecke dann auch praktisches Anschauungsmaterial: Jedes Getränk musste sofort und in bar bezahlt werden – „Deckel schreiben“ ist in (zumindest diesem Teil von) Finnland folgerichtig ein undenkbares Konzept.

LUST AUF NOCH MEHR DOMAIN-DRIVEN DESIGN-TRENDS?

Entdecke Workshops vom 25. - 27. November 2024

Mehr erfahren

Hildebrandt: Auch bei DDD kann man in die „Big Design Up Front“-Falle tappen! Ich habe beobachtet, wie ein Projektteam über einige Monate ein sehr umfassendes und detailliertes Modell der Domänen und Prozesse des Kunden erstellt hat. Das Vorgehen war dem Team nicht vorgegeben und die Option DDD war besprochen, aber vom Kunden nicht explizit beauftragt worden und die Modellierung ging weit über den Kontext des zu entwickelnden Systems hinaus, was den Beteiligten erst viel später klar wurde. Hier wäre ein etwas agileres und iteratives Vorgehen sinnvoll gewesen, um nicht nach wenigen Wochen in einer total gestressten Situation zu landen, aus der man sich erst nach Jahren wieder befreien konnte.

Hofer: Mich begeistern die „Aha-Momente“ in Collaborative-Modeling-Workshops (Event Storming, Domain Storytelling). Einmal meinte eine Teilnehmerin: „Ich arbeite seit 30 Jahren in der Abteilung, aber so habe ich noch nie über unsere Prozesse nachgedacht!“

Koch: In einem Projekt bei einem Logistiker warnten die Fachexperten vor komplexen „Kundenaufträgen aus der Hölle“, die teilweise aufgeteilt werden mussten, um mit der Auftragserfassung des Altsystems überhaupt erfasst werden zu können – was wiederum ihre Abwicklung und Abrechnung erschwerte. Nachdem wir zwei der kompliziertesten dieser Kundenaufträge genauer analysiert und nach DDD modelliert hatten, hatten alle diese „Höllenaufträge“ jeden Schrecken verloren: Dabei hatten wir nach DDD lediglich die Fachsprache softwaretechnisch nachmodelliert. Das war bereits die ganze Magie – und wir konnten viel schneller zum nächsten Thema übergehen als gedacht.

Lilienthal: Den größten Schock erleben Entwicklungsteams beim Umstieg auf DDD, wenn ihnen klar wird, dass sie sich vom Prinzip der Wiederverwendbarkeit verabschieden müssen. Bei DDD baut man kontextspezifische Domänenmodelle, die keine Klassen aus anderen Domänenmodellen wiederverwenden, nur weil dort schon eine Klasse Kunde oder Produkt oder Vertrag existiert. Die großen Augen mit vielen Fragezeichen zu redundanter Datenhaltung und Konsistenz und „Wie soll das denn gehen?“ sind immer wieder eine große Herausforderung in der DDD-Beratung und nach einiger Zeit lachen wir (Berater:innen und Kund:innen) dann gemeinsam über diese aufregende Anfangszeit.

Plöd: Mit einer „lustigen“ Geschichte kann ich nicht dienen, eher mit einer Geschichte, die eine traurige Ausgangssituation hatte: Fachbereich und Entwickler weigerten sich, direkt miteinander zu kommunizieren. Mit viel Mühe gelang es mir, beide Seiten zu einem gemeinsamen Event Storming in einen Raum zu bringen. Der Workshop begann damit, dass die Bereichsleiterin der Fachseite meinte „Ist das wieder so eine agile Post-it-Kleberei?“. Während des Workshops entstand mühsam, aber langsam ein spannender Kommunikationsfluss zwischen den beiden Abteilungen und man hörte immer häufiger Sätze wie „Was, das braucht ihr gar nicht?“ oder wie „Also, das können wir euch schnell bereitstellen“. In der Retrospektive meinte die Fachseite, dass sie das erste Mal das Gefühl hatten, von den Entwicklern wirklich gehört zu werden … Zwei Jahre später wollte die Fachabteilung unbedingt in das gleiche Großraumbüro wie das Entwicklungsteam ziehen. Direkte Kommunikation ohne Barrieren ist ungemein wichtig und sorgt für bessere Software.

Rauch: Als ich vor langer Zeit zum ersten Mal von DDD gehört hatte, war ich sehr begeistert und konnte auch meine Teamkollegen damit anstecken. Wir waren gerade dabei, eine große Altanwendung um ein kleines neues Modul zu ergänzen und haben im Zuge dessen beschlossen, DDD einmal auszuprobieren. Das lief auch wunderbar, der technikfreie Domänencode gefiel uns allen sehr gut, und durch die Verwendung von Repositories konnten wir die Tests auch sehr schön als kleine handliche Unit-Tests gestalten – die gewünschten Testdaten wurden durch verschiedene konkrete Testimplementierungen des Repository-Interface zugefüttert und fertig. Wir benötigten keine Datenbank mehr und konnten die Testlaufzeiten minimal halten – das war ein Novum für das Unternehmen, in dem die Ausführung aller Tests einer Applikation ansonsten oft Stunden dauerte. Wir hatten es auch geschafft, Specification by Example einzuführen, und die Fachabteilung war tatsächlich mit an Bord und erstellte fachliche Tests für uns – wir fühlten uns wie auf einer Wolke des Glücks. Leider hatten wir dabei völlig außer Acht gelassen, dass die Echtdaten, mit denen unser neuer Applikationsteil zu tun haben würde, deutlich komplizierter waren, als wir uns das bei der Implementierung unserer Test-Repositories so vorstellten. Und so schepperte es erstmal ganz schön, als wir die Applikation zum ersten Mal an eine Datenbank anbanden. Eigentlich kein Problem, wenn die Zeit bis zum geplanten Release nicht so unglaublich knapp gewesen wäre …

Es ist damals noch alles gut gegangen, aber daraus habe ich gelernt, dass es zwar sehr schön und hilfreich ist, dass man das Domain Layer für sich allein entwickeln kann, dass man aber trotzdem das drumherum befindliche Application Layer und auch die realen Daten nicht vergessen darf und den Domänencode früh und oft mit der realen Außenwelt integrieren muss.

Schwentner: Die DDD-Community ist ein Haufen von sehr freundlichen, offenen und lernbegierigen Leuten, von denen einige einen ziemlich verschrobenen Humor haben. Sucht in den Sozialen Netzen nach „DDD Borat“ und Ihr werdet sehen, was ich meine …

Wolff: Ich finde Eric Evans, den Autor des ursprünglichen DDD-Buchs, sehr beeindruckend. Ich hatte vor ca. 15 Jahren das Vergnügen, an einem Workshop mit ihm teilzunehmen und er begann mit Strategic Design – damals gingen mir gleich mehrere Lichter auf. Ebenso ist sein Paper zu „Getting Started with DDD when Surrounded by Legacy Systems“ [2] sehr beeindruckend. Beim Lesen habe ich mich mehrfach beim intensiven Kopfnicken wiedergefunden. Auch heute verkauft sich sein DDD-Buch sehr gut. Es ist seit 21 Jahren immer noch in der ersten Edition und hat eine ganze Designschule begründet. Das ist ein krasser Erfolg. Und dazu ist Eric nicht nur ausgesprochen intelligent, sondern auch eine sehr nette Person und hat andere zum Mitmachen bei DDD eingeladen – das finde ich super und darum ist das Thema heute so populär.

JM: Wo Licht ist, ist (wohl) auch Schatten: Kannst du auch über negative Erfahrungen mit DDD berichten?

Goeschel: Ich hatte es ja eingangs schon gesagt: In manchen Umfeldern ist DDD politisch brisant und deshalb gibt es durchaus manchmal Reibungsverluste. Mir fällt spontan ein Event-Storming-Workshop ein, in dem keine der 15 teilnehmenden Personen bereit war, auch nur einen einzigen Klebezettel zu beschriften – aus Angst, es könnte hinterher möglicherweise Ärger geben, wenn etwas falsch aufgeschrieben würde. Damit ist natürlich der Sinn und Zweck der Übung hinfällig. Gelöst habe ich das übrigens, indem ich alle Zettel selbst beschrieben und mir die Inhalte soufflieren lassen habe. Ein ziemlich unschönes Erlebnis, auch wenn am Ende ein Modell entstand, mit dem weitergearbeitet werden konnte.

Hildebrandt: Oft ist es in der IT über viele Teams schon schwierig, die gleichen Dinge gleich zu benennen, aber eine größere Herausforderung stellt die Verwendung einer gemeinsamen Sprache (Ubiquitous Language) in allen Fachbereichen und bei anderen nicht direkt an der Umsetzung Beteiligten in der Kommunikation zur Software dar, da viele Abteilungen ihren eigenen „Dialekt“ haben oder nicht täglich in der Sprache unterwegs sind. Hier sollten wenigstens die direkt Beteiligten überzeugt werden, damit Absprachen, Oberflächen und Dokumente konsistent sind. In der Folge kann es dann auch zu größeren Refactorings kommen, wenn sich der Sprachgebrauch im Unternehmen ändert, z. B. eine Onlinebestellung mit dem Einkauf vor Ort verschmolzen und in der Folge nur noch von Einkauf gesprochen wird. Das in der Domäne nachzuziehen, kann schon einen größeren Aufwand nach sich ziehen, bis hin zu Downtimes für DB-Migrationen.

Ein Punkt, der mir häufig auffällt, ist, dass dogmatisch eine der Standardarchitekturen (Hexagonal, Onion oder Clean) im Unternehmen ausgewählt und in der vollen Ausprägung verwendet wird, die im Kontext der konkreten Applikation aber keinen Nutzen bringt, da z. B. kaum Fachlogik in den Entitäten der Domäne existiert, sondern sich das Ganze in dem komplexen Mapping in Adaptern abspielt und nur zwei Kommunikationspartner existieren. In einem solchen Fall werden dann die Daten beim Eingang ins Domänenmodell transformiert, für die Persistenz in das DB-Model, dann wieder zurück ins Domänenmodell und schlussendlich ins Ausgangsmodell. In Summe muss dort viel Code erstellt und gewartet werden. Außerdem müssen – auch wenn in den Architekturstilen Tests einfach zu erstellen sind – viel mehr Tests erstellt werden. Auch bei der Massendatenverarbeitung kann es zu massivem Aufwand bei der Laufzeit kommen, was dann Aufwand bei der Implementierung nach sich zieht. So werden aus kleinen, kompakten Systemen richtig aufwendig zu pflegende Systeme.

Hier wäre es hilfreich, die Elemente der Architekturstile zu kennen und diese bei Bedarf einzusetzen, wie es in anderen Kontexten üblich ist. Ein stark typisiertes Modell („Ein Name ist ein Name und kein String“) ist im Quellcode – wenigstens für Java-Entwickler – immer eine gute Wahl! Ports und Adapter sind bei „externen“ Schnittstellen auch eine wichtige Option, bei „internen“ Schnittstellen – innerhalb eines SCS ggf. auch zum Frontend – erzeugen sie möglicherweise mehr Aufwand, machen den Code weniger lesbar und fehleranfälliger. Daher sollten sie nicht ohne Grund eingesetzt werden. Das Gleiche gilt für die Entkopplung der Datenhaltung über ein eigenes Modell mit Mapping. Dieses ist bei viel Fachlogik in den Domänenklassen für eine technologiefreie Modellierung und Tests sehr hilfreich, weniger komplexe Domänenmodelle lassen sich aber auch mit JPA inkl. guter Typisierung erstellen und bei Tests gut handhaben.

Am Ende ist es wichtiger, die Fachlichkeit verstanden und gut umgesetzt zu haben, sodass Anwender des Systems zufrieden sind und Anforderungen in einer guten Qualität und verlässlicher Geschwindigkeit für den Auftraggeber planbar umgesetzt werden können, als sich an alle Elemente in einer Beispielarchitektur zu halten. Dafür ist der fachliche Teil wichtig, aber auch ein inkrementeller Ansatz, da auch bei DDD das Lernen nicht vor der Umsetzung abgeschlossen ist.

Hofer: Wenn die Voraussetzungen nicht stimmen, bringt die beste Methodik nichts: Fachleute, die keine Zeit für Collaborative-Modeling-Workshops eingeräumt bekommen, strategisches Design mit der Vorgabe, keinesfalls die bestehende Aufgabenverteilung der Teams zu ändern oder eine Ubiquitous Language, die nicht vom Datenmodell der IT-Unternehmensarchitektur abweichen darf.

Koch: Viele Teams und Fachexperten tun sich schwer, in separaten Subdomänen zu denken oder Fachliches von Technischem zu trennen – es wird oft alles als ein großes Ganzes gesehen. DDD erscheint dann paradoxerweise kompliziert und die Fachlichkeit zu komplex.

Da DDD auf einem guten Verständnis der Fachlichkeit basiert, wird häufig zu viel analysiert, bevor überhaupt mit der Umsetzung begonnen wird. Das ist dann sehr un-agil.

In manchen Projekten existieren sehr konkrete Vorstellungen davon, wie das Zielsystem auszusehen hat (Architektur, UI, …). Der Blick auf die Fachdomäne fühlt sich dann manchmal „abstrakt“ an (weit weg von der Software) und wie ein Schritt zurück.

Einige DDD-Konzepte sind auch nach 21 Jahren noch immer schwer greifbar (z. B. die „Subdomäne“). Es fehlt eine gute, allgemein anerkannte Definition, stattdessen existieren unterschiedliche Interpretationen nebeneinander, die eine Diskussion über DDD erschweren.

Lilienthal: Einmal wurde ich von einem Kunden zu einem DDD-Workshop gebeten, weil die vorhandene IT-Landschaft zu Microservices umgebaut werden sollte. Als ich dort war, zeigte mir der externe Berater die IT-Landschaft und sagte: „Sehen Sie mal: Hier ist der Kunde und da ist der Kunde – eigentlich überall und wir haben dadurch ganz viele Doubletten. Das wollen wir mit Microservices zusammenlegen, sodass der Kunde nur noch einmal existiert und im ganzen System immer konsistent ist!“ Nun war ich echt in einer Zwickmühle: Einerseits wollte ich den externen Berater, der eine Service-orientierte Architektur mit einem Kundenservice als Microservices nach DDD verkauft hatte, nicht blamieren. Andererseits musste ich dem Kunden reinen Wein einschenken, dass seine IT-Landschaft eigentlich genau das tut, was DDD will: Lokale Domänenmodelle pro Bounded Context und deshalb auch den Kunden mehrfach in der IT-Landschaft jeweils spezifisch zu dem Kontext, wo er gebraucht wird. Ich habe dann vorsichtig Hinweise gegeben, bis dem externen Berater ein Licht aufging und wir haben gemeinsam die Kurve gekriegt. Zum Glück …

Plöd: Negative Erfahrungen entstehen immer dann, wenn bestimmte Methodiken oder Patterns aus dem DDD-Umfeld primär aus reinem Selbstzweck eingesetzt werden, damit man „DDD-kompatibel“ (ein fürchterlicher Begriff!!) ist. Man findet das ganz häufig im Umfeld des Tactical Designs, wo dann z. B. durch hexagonale Architekturen ein Overkill an Stellen entsteht, wo das Architekturmuster keinen Mehrwert liefert. Gleiches gilt für den Einsatz der Methoden der kollaborativen Modellierung, wenn strikt vorgeschrieben ist, welche Methodik wann genau zum Einsatz kommen muss. Ich denke, das sollten die Teams für sich entscheiden und bewerten. DDD ist keine Religion und das Buch von Eric Evans ist, auch wenn es noch heute absolut lesenswert ist, nicht die heilige Bibel.

Rauch: Als negative Erfahrung mit DDD selbst würde ich es jetzt nicht unbedingt bezeichnen, aber ich denke, dass es wichtig ist, sich darüber klar zu sein, dass der Einsatz von DDD mit erheblichem Aufwand und damit auch mit Kosten verbunden ist. Es ist z. B. wichtig, den Code immer wieder an neue Erkenntnisse anzupassen, und sei es auch nur bei so „trivialen“ Dingen wie dem Finden eines besseren Begriffs für einen bestimmten Sachverhalt. Hier ist es erforderlich, nicht nur das Glossar der Ubiquitous Language, sondern auch den gesamten Code bis hinunter zur Datenbank anzupassen. Auch neue Erkenntnisse im Hinblick auf die Modellierung einer bestimmten Fachlichkeit, die sogenannten „Modelling Breakthroughs“, müssen ständig in den Code einfließen. Diese wiederkehrenden Änderungen sind ein ganz normaler Prozess in DDD, sie sorgen dafür, dass das Domänenmodell „geschmeidig“ und damit leicht anpassbar und erweiterbar ist. Auf lange Sicht bringt diese Vorgehensweise also einen enormen Mehrwert, doch wenn das Unternehmen nicht bereit ist, die Kosten zu tragen, oder wenn ein Team absehbar nicht in der Lage ist, diese Arbeit zu investieren, dann ist DDD vermutlich nicht die beste Wahl. Es ist wichtig, sich darüber schon im Vorfeld klar zu sein, um später nicht enttäuscht zu werden.

Schwentner: Manche Projekte tragen das „Blaue Buch“ wie eine heilige Schrift vor sich her, nach dem Motto: „Wir machen alles genau, wie es hier drinsteht.“ DDD hat sich in den letzten zwei Jahrzehnten weiterentwickelt und es ist auch kein Wundermittel, das Lahme zum Gehen bringt. Aber es hilft dabei, sich auf das Wesentliche zu fokussieren: unsere Anwender verstehen und dadurch in die Lage kommen, großartige Software zu bauen. Und damit können dann durchaus lahme Systeme wieder zum Laufen gebracht werden.

Wolff: Eines der großen Probleme in der Softwareentwicklung ist das Benennen von Dingen. Domain-Driven Design löst das sehr gut: DDD bedeutet, dass die Domäne das Design treibt. Aber trotzdem gibt es sogar dabei Missverständnisse: Wenn der Fachbereich oder die Benutzer:innen nicht an der Entwicklung beteiligen sind, kann man kaum sicherstellen, dass Techniker:innen die Domäne verstehen – wie soll sie dann das Design treiben? Leider ist aber zu oft mindestens den Techniker:innen unklar, welche geschäftliche Bedeutung ein Projekt hat. Damit geht die Essenz von DDD verloren: Die Orientierung an der Fachlichkeit. Das ist viel wichtiger als diese oder jene Technik oder wie Klassen in einem System benannt sind. Leider geht aber genau das verloren.

JM: Bitte vervollständige den folgenden Satz: Für die nächsten 21 Jahre DDD wünsche ich mir …

Goeschel: … dass der aktuelle Trend zu immer systemischeren und ganzheitlichen Denkweisen sich fortwährend und flächendeckend durchsetzt. In den letzten zwei bis drei Jahren hat sich in der DDD-Community bspw. mit Team Topologies, Wardley Maps und Data Mesh eine ganze Reihe neuer Werkzeuge etabliert, die neben der reinen Programmierung auch Daten, Strategie und Zusammenarbeitsmodelle in den Fokus nehmen. DDD ist damit längst nicht mehr nur eine Geschmacksrichtung von Softwarearchitektur, sondern Grundlage für die Gestaltung ganzer Unternehmen. Für die großen Umwälzungen in Richtung Digitalisierung, die wir in den nächsten Jahren zu erwarten haben, wird der kluge Einsatz dieser Mittel entscheidend sein.

Hildebrandt: … einen reflektierten Umgang mit den Möglichkeiten und Werkzeugen, die DDD bietet, um es an den Stellen einzusetzen, an denen ein Mehrwert entsteht, und auf Elemente zu verzichten, wenn sie in der Software nur Ballast sind.

Hofer: … dass mit der Popularität nicht so viele Missverständnisse und überzogene Heilsversprechen einhergehen, wie das z. B. bei Agilität und Microservices der Fall war. Und um mit etwas Positivem zu enden: Zum 15-jährigen Jubiläum von DDD rief Eric Evans mit dem Motto „DDD is not over yet“ zur Weiterentwicklung auf. Ich wünsche mir viele neue, gute Ideen!

Koch: … mehr Diskussion und Experimentierfreude im Bereich praktischer Methoden, die die Anwendung von DDD unterstützen.

Lilienthal: … dass immer mehr Softwareentwicklungsteams die Qualität ihrer Legacy-Software mit DDD zu verbessern lernen und dass neue Systeme nur noch mit dem DDD-Blick auf die Fachlichkeit und die Anwender:innen gebaut werden.

Plöd: … weiterhin eine so offene und umtriebige Community, die das Thema immer weiterentwickelt, und ein weiteres Zusammenwachsen von Business und IT.

Rauch: … zwei Dinge: Zum einen beobachte ich einen immer stärker werdenden Technikwahn, und es werden Frameworks und Libraries benutzt, ohne dass richtig verstanden wird, ob man sie wirklich braucht und welche Nachteile man sich dadurch einhandelt. Oft wird der Code dadurch unnötig kompliziert, was die Nachvollziehbarkeit und Testbarkeit erschwert. Hier wünsche ich mir mehr Rückbesinnung auf das, was tatsächlich technisch notwendig ist, um so hin zu klarem, gut verständlichem Domänencode zu kommen.

Zum anderen finde ich es immer wieder erschreckend, wie viel Technik in den Entwicklungsprozess an und für sich gedrückt wird, sowohl für das Management der Anforderungen als auch des Codes mit starren Reviewtools und Ähnlichem.

Dabei möchte Domain-Driven Design (genau wie agile Vorgehensweisen übrigens auch) meiner Meinung nach hauptsächlich eins erreichen: Dass die Entwickler und die Domänenexperten endlich mal direkt und ungefiltert miteinander sprechen und so das gemeinsame Verständnis bestmöglich voranbringen. Denn um Alberto Brandolini zu zitieren: „Es ist nicht das Wissen des Fachexperten, sondern das Verständnis des Entwicklers, das in der Produktionsumgebung bereitgestellt wird.“ Ich wünsche mir, dass wir das in 21 Jahren verstanden haben werden.

Schwentner: a) … dass noch mehr Programmiererinnen und Programmierer verstehen, dass Softwareentwicklung kein Selbstzweck ist, sondern wir Software bauen, um unseren Anwendern das Leben leichter zu machen.

b) … sie sich in Theorie und Praxis in DDD ausbilden, sei es durch das Lesen von Büchern, in Trainings oder und gerade durch Ausprobieren im eigenen Projekt.

c) … weitere Werkzeuge in die Werkzeugkiste „Collaborative Modeling“ hinzukommen und Event Storming und Domain Storytelling ergänzen.

Wolff: Am Ende weist DDD jedoch auf ein fundamentales Problem bei der Softwareentwicklung hin: Die Domäne zu verstehen, um das Richtige zu bauen. Das wird voraussichtlich auch in 21 Jahren noch die wichtigste Herausforderung in der Softwareentwicklung sein und begleitet mich schon meine gesamte Karriere. Daran werden neue, produktivere Werkzeuge und Technologien nichts ändern. Aber ich finde es schwierig, über einen so langen Zeitraum Dinge vorherzusehen oder sich zu wünschen. Zudem sind die Umstände zu diesem Zeitpunkt deutlich anders: Ich bin dann vermutlich im Ruhestand. Dank der Untätigkeit bezüglich der Klimakatastrophe wird die Welt 2043 sicher auch sehr anders aussehen.

JM: Vielen Dank!

Die Fragen stellte Marius Nied.