Domain-Driven Transformation: Monolithen und Microservices zukunftsfähig machen

Von Carola Lilienthal und Henning Schwentner

Über den Umbau von IT-Landschaften mit Domain-Driven Design

- kompakter, tiefgehender Einblick in Domain-Driven Design (DDD) und die Verwendung der vielfältigen DDD-Techniken in der Praxis – Fokussierung auf Legacy-Systeme und Migration in Richtung gut strukturierter Monolithen und Microservices
- Zusammenhang zwischen Transformation der Architektur und der TeamorganisationIn den letzten Jahrzehnten ist sehr viel Software entwickelt worden, die wir heute modernisieren und zukunftsfähig machen wollen. Domain-Driven Design (DDD) eignet sich hervorragend, um große Legacy-Systeme in Microservices zu zerlegen oder zu wartbaren Monolithen umzubauen. In diesem Transformationsprozess wird der fachliche Kern des Softwaresystems herausgearbeitet. Auf der Makro-Architektur-Ebene wird das System in unabhängige DDD-Module aufgeteilt. Auf der Mikro-Architektur-Ebene werden zusätzlich DDD-Muster eingesetzt, um den Code weiter zu strukturieren.  
Dieses Buch kombiniert Anleitungen, Erkenntnisse und Beispiele aus der Beraterpraxis des Autorenteams. Es veranschaulicht, wie Techniken aus DDD und Refactorings verwendet werden können, um Softwaresysteme zu transformieren, die über Jahre gewachsen und möglicherweise ohne Architekturverständnis entwickelt wurden. Die Leser*innen lernen einen Prozess der Transformation kennen, den sie als Ganzes oder schrittweise in ihre Alltagspraxis übernehmen können, um die Wartbarkeit ihrer Legacy-Systeme effektiv und schnell zu verbessern. Sie erhalten:

- einen detaillierten Einblick in DDD und die Verwendung der vielfältigen DDD-Techniken in der Praxis,
- eine Anleitung, wie DDD eingesetzt werden kann, damit Legacy-Systeme wartbar bleiben oder wartbarer werden,
- eine Anleitung, wie vorzugehen ist, falls eine Zerlegung der Monolithen und eine Neustrukturierung der Microservices geplant ist,
- Argumente an die Hand, wann eine Zerlegung in Microservices für einen Monolithen sinnvoll ist und wann nicht. 

• Sprache: Deutsch
• Herausgeber: dpunkt.verlag
• Erscheinungsdatum: 4. Sept. 2023
• ISBN: 9783969107652

Buchvorschau

1Einleitung: Komplexität beherrschen

Wenn man auf der grünen Wiese mit einem Softwareprojekt anfängt, macht alles Spaß und alles ist einfach. Die Entwickler reagieren blitzschnell auf neue Anforderungen. Die Anwender sind begeistert. Die Entwicklung geht in großen Schritten voran.

Über die Lebenszeit des Systems wird sich das ändern. Unweigerlich erhöht sich die Komplexität der Software. Diese ansteigende Komplexität führt zu höherer Fehleranfälligkeit, immer langsamerem Fortschritt und schlechterer Wartbarkeit. Und schließlich braucht es ein halbes Jahr, bis auch nur die kleinste Änderung in Produktion angekommen ist. Aus der blühenden grünen Wiese ist ein schlammiger, stinkender Acker geworden. »Altsystem«, »Legacy-Software«, »Big Ball of Mud«, »Monolith«, »Gummistiefelprojekt« sind die wenig schmeichelhaften Namen, mit denen diese Art von Systemen versehen werden.

»The most fundamental problem in software development is complexity. There is only one basic way of dealing with complexity: divide and conquer.«

Bjarne Stroustrup

Aber es gibt Hoffnung! Auch diesen in die Jahre gekommenen Systemen kann Flexibilität, Fehlerrobustheit und Entwicklungsgeschwindigkeit zurückgegeben werden. Kernaufgabe ist dabei die Beherrschung (und Aufteilung) von Komplexität.

1.1Komplexität

Um einordnen zu können, wie mit Komplexität bei der Softwareentwicklung umgegangen werden kann, ist der Untertitel von Eric Evans’ Buch Domain-Driven Design ein guter Wegweiser: Tackling Complexity in the Heart of Software [Evans 2004]. Evans gibt uns das Versprechen, dass das von ihm beschriebene Vorgehen Komplexität in der Software(-entwicklung) reduziert oder zumindest handhabbar macht. Domain-Driven Design hilft dabei auf unterschiedlichen Ebenen. In Abbildung 1–1 sind die verschiedenen Aspekte von Komplexität, die uns bei der Softwareentwicklung begegnen, in Anlehnung an [Lilienthal 2008] und [Lilienthal 2019] zusammengefasst.

Abb. 1–1Komplexität und ihre Quellen

Im weiteren Verlauf werden wir sehen, dass die Grundlagen, die wir im ersten Teil des Buches einführen, Methoden und Heuristiken für bestimmte in Abbildung 1–1 aufgeführte Komplexitätsquellen anbieten. Wir werden diese Abbildung in den nächsten Abschnitten daher wiedersehen und sie Schritt für Schritt mit weiteren Informationen füllen.

1.2Herkunft der Komplexität: Problem- und Lösungsraum

Die Herkunftsdimension von Komplexität bei der Softwareentwicklung ist in Abbildung 1–1 auf der vertikalen Achse dargestellt. Diese Komplexität entsteht aus dem Wunsch, für eine Domäne eine Software zu bauen; also von der Domäne, einem Teil der wirklichen Welt (dem sog. Problemraum), zu einer Software mit passenden Geschäftsprozessen (in den sog. Lösungsraum) zu kommen. Wir haben somit zwei Quellen:

Problemraum: die Komplexität der Fachdomäne, für die das Softwaresystem gebaut wurde – die sogenannte probleminhärente Komplexität

Lösungsraum: die Komplexität, die in der Umsetzung bei der Modellierung, in der Architektur und bei der Verwendung der gewählten Technologie entsteht – die sogenannte lösungsabhängige Komplexität

In den letzten Jahrzehnten hat unser Berufsstand bei der Softwareentwicklung immer wieder die Erfahrung gemacht, dass es sehr schwer, wenn nicht gar unmöglich ist, die Komplexität im Problemraum am Anfang eines Projekts abzuschätzen und in einem Pflichtenheft niederzuschreiben. Deshalb dauern Projekte häufig viel länger als geplant, deshalb funktioniert das Wasserfallmodell so schlecht und deshalb sind agile Methoden so populär geworden. Richtig angewandt sind agile Methoden nämlich eine gute Hilfe, denn sie versuchen, die Komplexität im Problemraum in kleineren Häppchen Schritt für Schritt verschränkt mit der Umsetzung zu erfassen.

1.3Art der Komplexität: essenziell vs. akzidentell

In Abbildung 1–1 findet sich auf der horizontalen Dimension die Art der Komplexität mit den beiden Begriffen essenziell und akzidentell. Welche Anteile von Komplexität werden mit diesen beiden Begriffen beschrieben?

Haben wir das weltbeste und erfahrenste Team im Einsatz, dann können wir erwarten, dass wir eine gute Softwarelösung bekommen. Eine Softwarelösung, die eine für das Problem angemessene Komplexität aufweist. Ist die vom Entwicklungsteam gewählte Lösung komplexer als das eigentliche Problem, dann konnte das Entwicklungsteam die essenzielle Komplexität nicht richtig erfassen und die Lösung ist zu komplex, also nicht gut. Dieser Unterschied zwischen besseren und schlechteren Lösungen wird mit essenzieller und akzidenteller Komplexität bezeichnet.

Essenzielle Komplexität nennt man die Art von Komplexität, die im Wesen einer Sache liegt, also Teil seiner Essenz ist. Diese Komplexität lässt sich niemals auflösen oder durch einen besonders guten Entwurf vermeiden. Will man eine Software für eine komplexe Domäne bauen, für eine Domäne, bei der eine hohe Komplexität Teil ihres Wesens – ihrer Essenz – ist, so wird auch die Komplexität in der Software im Lösungsraum hoch ausfallen müssen. So hat eine Softwarelösung für ein Containerterminal eine größere essenzielle Komplexität als eine Software zur Verwaltung von Vereinsmitgliedern in einem Ruderclub.

1.3.1Quellen akzidenteller Komplexität

Akzidentelle Komplexität ist im Gegensatz zur essenziellen nicht notwendig. Sie entsteht aus folgenden Gründen:

aus Missverständnissen bei der Analyse der Fachdomäne, sodass uns die Fachdomäne komplexer erscheint, als sie eigentlich ist;

weil wir glauben, dass die Anwender für bestimmte Arbeitsschritte Unterstützung brauchen, obwohl sie eigentlich ganz anders arbeiten, und wir somit Sachen bauen, die keiner braucht;

weil wir uns für ein schlechtes Design und eine schlechte Architektur entscheiden bzw. Design und Architektur mit der Zeit durch Wartung, Änderung und Unkenntnis erodieren;

weil wir unpassende oder veraltete Technologie einsetzen, die ersetzt werden muss, oder weil wir die Technologie nicht so verwenden, wie es eigentlich vorgesehen war.

Wird bei der Entwicklung aus Unkenntnis oder mangelndem Überblick keine einfache Lösung gefunden, so ist das Softwaresystem unnötig komplex. Beispiele hierfür sind: Mehrfachimplementierungen, Einbau nicht benötigter Funktionalität und das Nichtbeachten softwaretechnischer Entwurfsprinzipien. Akzidentelle Komplexität kann von Entwicklern aber auch billigend in Kauf genommen werden, wenn sie z.B. gern neue, aber für das zu bauende Softwaresystem überflüssige Technologie ausprobieren wollen.

1.3.2Entscheidungsbereiche von Softwarearchitektur

Im Foundation Training des iSAQB – International Software Architecture Qualification Board (s. [iSAQB 2023]) –, der Basisausbildung für Softwarearchitekten, werden vier Bereiche definiert, die für die Entscheidungen über die Softwarearchitektur relevant sind: Anforderungsermittlung, Modellbildung, fachliche Architektur und technische Architektur. Diese vier Bereiche bzw. die in diesen Bereichen vorhandenen Methoden und Techniken lassen sich sehr gut auf Abbildung 1–1 anwenden.

Abb. 1–2Komplexität und Architektur

In Abbildung 1–2 können Sie sehen, dass Anforderungsermittlung und Modellbildung im Problemraum sowohl auf der essenziellen als auch auf der akzidentellen Seite ansetzen. Fachliche und technische Architektur wirken auf die essenzielle und akzidentelle Komplexität im Lösungsraum. Die Methoden und Techniken der Anforderungsermittlung, der Modellbildung, der fachlichen und technischen Architektur werden sowohl bei der Neuentwicklung als auch bei der Transformation von Legacy-Systemen eingesetzt, um die essenzielle Komplexität herauszudestillieren und möglichst viel akzidentelle Komplexität in unseren Systemen zu eliminieren (s. Abb. 1–3).

Abb. 1–3Einsatz von Methoden gegen Komplexität

Vollständig werden wir die akzidentelle Komplexität selbst mit den besten Methoden nicht auflösen können, denn wir befinden uns bei der Softwareentwicklung und Softwarewartung in einem kontinuierlichen Lernprozess. Dieser Lernprozess beinhaltet, dass wir Teile der Fachlichkeit und der Technologie immer wieder missverstehen und überflüssige oder schlechte Lösungen für Teilbereiche konzipieren oder implementieren. Deshalb bleibt selbst bei perfekter Umsetzung auf allen Ebenen in Abbildung 1–3 ein Anteil akzidenteller Komplexität bestehen.

1.4Komplexität in Legacy-Systemen

Bei Legacy-Systemen, die schon eine Anzahl von Jahren auf dem Buckel haben und von verschiedensten Generationen von Entwicklern gewartet und verändert worden sind, ist viel akzidentelle Komplexität zu erwarten. Gründe dafür sind:

Die Arbeit der Anwender und damit die Fachdomäne hat sich im Laufe der Jahre verschoben. Neue Funktionalität wurde der Software hinzugefügt, um die Anwender auch bei ihren neuen oder etwas veränderten Aufgaben zu unterstützen. Aber die Domänenmodellierung und die fachliche Modularisierung des Softwaresystems in der Architektur wurden an diese Verschiebung nicht oder nicht ausreichend angepasst.

Die Entwickler und Architekten des Systems haben über die Jahre aus Zeitdruck, aus Unkenntnis oder aus Desinteresse das ursprüngliche Design und die Architektur verwässert und die einzelnen Teile immer stärker miteinander verwoben und so voneinander abhängig gemacht.

Jede Technologie veraltet in unserer Disziplin und muss alle 10 bis 15 Jahre durch etwas Neues ersetzt werden. Bei Legacy-Systemen wird der richtige Zeitpunkt häufig verpasst.

Als Evans sein Buch 2004 schrieb, ging es ihm um die Neuentwicklung von Software, also um die Frage: »Was muss ich tun, damit mein neues Softwaresystem domänengetrieben designt ist?« In diesem Buch übertragen wir die Ideen von Domain-Driven Design (DDD) auf Legacy-Systeme. Wir durften in den vergangenen Jahren feststellen, dass wir in DDD Konzepte und Anleitungen finden, die sich für die nötige Neukonzeptionierung und den zum Teil umfassenden Umbau von Legacy-Systemen hervorragend eignen.

Schlüssel dazu ist die schrittweise und behutsame Modernisierung mithilfe einer Kombination aus DDD und weiteren Werkzeugen, die wir im Laufe des Buches einführen.

1.5Struktur dieses Buches

Das Buch besteht neben dieser Einleitung (Kap. 1) – in der wir unseren Begriff von Komplexität erläutert haben – aus drei Teilen, dem Abschluss und einer Website:

Teil I, »Grundlagen für Domain-Driven Transformation«, fasst das benötigte Basiswissen zusammen. Hier zeigen wir, was Domain-Driven Design (Kap. 2) und Collaborative Modeling (Kap. 3) sind und welche Architekturkonzepte (Kap. 4) für das Verständnis dieses Buches wichtig sind. Von diesen drei Kapiteln sollten Sie sich die Abschnitte bzw. Themen heraussuchen, in denen Sie sich nicht firm fühlen.

Im abschließenden Kapitel von Teil I beantworten wir die Frage nach dem richtigen Vorgehen (Kap. 5). Dieses Kapitel ist wichtig für das Gesamtverständnis der nachfolgenden Teile – wir empfehlen es Ihnen daher auf jeden Fall.

Teil II, »Technische, taktische und teamorganisatorische Domain-Driven Transformation«, zeigt, wie das Altsystem auf diese große Verbesserung vorbereitet werden kann. Grundsätzlich lohnt es sich, das Altsystem technisch zu stabilisieren (Kap. 6) und mit taktischer Domain-Driven Transformation die Fachlichkeit im Sourcecode zu stärken (Kap. 7). Und schließlich sollte das Entwicklungsteam Klarheit haben, wie die Teamstrukturen aussehen sollen, wenn man sich auf den Weg einer strategischen Transformation des Altsystems begibt (Kap. 8).

Teil III, »Strategische Domain-Driven Transformation«, stellt das von uns entwickelte Vorgehen zum Zerlegen vor. Das Vorgehen besteht aus vier Schritten: Es beginnt mit dem Wiederentdecken der Fachdomäne (Kap. 9), führt über das Modellieren der fachlichen Soll-Architektur (Kap. 10) und den Abgleich Ist- mit Soll-Architektur (Kap. 11) und endet beim Priorisieren und Durchführen der Umbaumaßnahmen (Kap. 12).

Im »Ausblick: Domain Patterns und ihre Umsetzung in Kontexten« (Kap. 13) stellen wir Ihnen unsere Ideen dazu vor, welche Domänenmuster es gibt, und wie sich das jeweilige Domänenmuster auf die Domain-Driven Transformation auswirkt. Im »Fazit« (Kap. 14) fassen wir das Buch abschließend zusammen.

Um die Transformation durchzuführen, braucht man Domain-Driven Refactorings, die online in einem Katalog gesammelt werden: https://hschwentner.io/domain-driven-refactorings. Wir geben an verschiedenen Stellen im Buch konkrete Referenzen auf das jeweilige zu verwendende Refactoring.

Teil I

Grundlagen für Domain-Driven Transformation

Als Domain-Driven Design – später bekannt als das »Blaue Buch« – von Eric Evans im Jahr 2004 veröffentlicht wurde [Evans 2004], fand es am Anfang wenig Beachtung außerhalb eingeweihter Kreise. Erst als Microservices um 2012 herum als neuer Architekturstil für die Skalierung von großen Softwaresystemen aufkamen, wurde das Buch neu entdeckt. Denn Domain-Driven Design hat nicht nur mit dem sogenannten taktischen Design sinnvolle Entwurfsmuster im Angebot. DDD bietet vielmehr auch eine Methodik an, wie man Domänen in Subdomänen zerlegen und die so entstehende fachliche Struktur auf die Modularisierung von Softwaresystemen – ob nun monolithisch oder eben aus Microservices – übertragen kann: das strategische Design.

An der Menge der Veröffentlichungen, die zu Domain-Driven Design in den Jahren nach 2012 erschienen sind, ist abzulesen, wie wichtig diese Konzepte für die Softwareentwicklung geworden sind. 2013 kam das Buch von Vaughn Vernon heraus: Implementing Domain-Driven Design – genannt das »Rote Buch« [Vernon 2013] –, das einerseits viele gute praktische Tipps zur Implementierung nach DDD gegeben, aber auch angefangen hat, weitere Begriffe und Konzepte hinzuzufügen. 2015 dann erschien Patterns, Principles, and Practices of Domain-Driven Design von Scott Millet und Nick Tune [Millet & Tune 2015]. Vernon hat noch weitere Bücher zu DDD geschrieben (s. [Vernon 2017], [Vernon & Jaskula 2022]), deren Erweiterungen und Erkenntnisse wir im nächsten Kapitel zu DDD (s. Kap. 2) mit aufnehmen. Ein gutes, gerade auf Deutsch erschienenes Buch ist [Khononov 2022].

Event Storming wurde zur gleichen Zeit wie das erste Buch von Vaughn Vernon, 2013, von Alberto Brandolini auf Konferenzen vorgestellt [Brandolini 2021] und u.a. als Unterstützung beim Zerlegen von Software in unabhängige Module bekannt. Wenig später haben Stefan Hofer und Henning angefangen, Domain Storytelling als weitere Methode für das Zerlegen öffentlich zu machen, was schließlich in ihr gleichnamiges Buch mündete (s. [Hofer & Schwentner 2023]). Event Storming und Domain Storytelling gehören zu einer Familie von leichtgewichtigen Methoden, die unter dem Namen Collaborative Modeling bekannt sind. Diesen Methoden widmen wir das Kapitel 3 in diesem Grundlagenteil.

Auch Eric Evans selbst hat weitere Texte zu Domain-Driven Design verfasst: 2013 veröffentlichte er einen 20-seitigen Artikel mit dem Titel Getting Started with DDD When Surrounded by Legacy Systems (s. [Evans 2013]), in dem er Bubble Contexts und vier Strategien vorstellt, wie man sie beim Modernisieren von Legacy-Systemen einsetzen kann. 2015 schrieb er schließlich eine 50-seitige Kurzfassung seines Buches mit dem Titel Domain-Driven Design Reference: Definitions and Pattern Summaries (s. [Evans 2015]). Auch diese Arbeiten haben uns auf unserem Weg bis zu diesem Buch über DDD inspiriert und begleitet und werden an den entsprechenden Stellen wieder auftauchen.

Im Vorwort der DDD Reference bedankt sich Evans bei allen, die schon Beiträge zum Thema DDD geleistet haben, und hofft auf viele neue Artikel, Blogs und Bücher, damit der DDD-Ansatz weiter wächst und gedeiht. Wir hoffen mit unserer Sicht auf Domain-Driven Design und Legacy-Systeme einen weiteren Baustein zum DDD-Ansatz beizutragen.

Die grundlegenden Methoden

In den folgenden drei Grundlagenkapiteln stellen wir Ihnen unser Verständnis von Domain-Driven Design (s. Kap. 2), Collaborative Modeling (s. Kap. 3) und Architekturkonzepte (s. Kap. 4) vor. Diese drei Methoden bzw. Konzepte decken den gesamten Komplexitätsraum ab, den wir am Anfang dieses Überblickskapitels mit Abbildung 1–1 vorgestellt und mit Abbildung 1–2 auf Architektur bezogen haben. In Abbildung I–1 sieht man, wo sie jeweils ansetzen.

Abb. I–1Komplexität und Methoden

Collaborative Modeling deckt den Bereich der Anforderungsermittlung ab, der uns den Zugang zu Geschäftsprozessen, Rollen und Arbeitsgegenständen im Problemraum gibt.

Domain-Driven Design ist für die Komplexitätsbereiche in der Mitte der Abbildung zuständig. DDD hat sowohl im Problembereich als auch im Lösungsbereich Konzepte zu bieten. DDD kümmert sich ausschließlich um die fachlichen Anteile bei der Softwareentwicklung, zu denen die Modellbildung im Problemraum sowie Design und Architektur im Lösungsraum zählen.

Zur Komplexität der Technologie hingegen und zu den Missverständnissen, die beim Einsatz von Technologie zu akzidenteller Komplexität führen können, hält sich Domain-Driven Design bewusst zurück. Das macht DDD so universell einsetzbar und langlebig – es ist nicht technologieabhängig, sondern kümmert sich um den für den Erfolg einer Software entscheidenden Kern: die Fachlichkeit. Denn die Software soll die Anwender bei ihrer fachlichen Arbeit unterstützen – die Technologie ist aus diesem Blickwinkel nur ein Mittel zum Zweck.

Damit die Technologie trotzdem gut gelingt, haben Architekten und Softwareentwickler in den letzten Jahrzehnten Architekturkonzepte beschrieben, die uns helfen, die akzidentelle Komplexität im Lösungsraum zu reduzieren.

Komplexität sichtbar machen mit Architekturdokumentation

Um Komplexität zu erkennen, hilft es, sie sichtbar zu machen. Zur Dokumentation von Architektur gibt es verschiedene Ansätze wie UML, Archimate und Arc42. Wir werden in diesem Buch das C4 Model verwenden, um Ihnen unsere Beispiele nahezubringen, deshalb führen wir die C4-Notation hier am Anfang ein.

Das C4 Model

Für die Visualisierung von Architektur hat sich in den letzten Jahren neben UML und Co. eine leichtgewichtige Variante etabliert: das sogenannte C4 Model (s. [Brown 2023]). Die Idee ist es, sich der Architektur vom Groben zum Feinen zu nähern. Vier sogenannte Levels sind definiert, deren Namen jeweils mit dem Buchstaben C beginnen: Context, Containers, Components, Code.

Auf allen Ebenen des C4 Model können Personen, Architekturelemente und Beziehungen dargestellt werden. Jedes feinere Level beschreibt ein Architekturelement aus dem gröberen Level in seinen Bestandteilen.

Alle Diagramme sollen so selbsterklärend wie möglich sein und eine Legende aufweisen. Die Architekturelemente enthalten typischerweise einen erläuternden Text.

Level 1: Context

Hier wird das System im Ganzen in seiner Umwelt mit Benutzern und verbundenen Systemen dargestellt.

Level 2: Containers

Es wird in das System hineingezoomt und betrachtet, aus welchen Deployment-Einheiten – Container genannt – das System besteht. Ein Container ist ein eigener Prozess. Achtung: Container im C4-Sinne können, müssen aber nicht in Containern im Sinne von Docker laufen.

Level 3: Components

Nun betrachten wir die Teile des einzelnen Containers – die sogenannten Components. Mehrere Components laufen im gleichen Prozess.

Level 4: Code

Schließlich zoomen wir in die einzelne Component hinein und betrachten die Code-Ebene, d.h. aus welchen Klassen und Methoden die Component besteht.

Erste Beispiele für C4-Diagramme werden in den Abbildungen 2–2 und 2–3 zu sehen sein.

Wie weiter?

Werfen wir in diesem ersten Teil des Buches nun also einen Blick auf Domain-Driven Design, Collaborative Modeling und Architekturkonzepte, die wir als Grundlage für Domain-Driven Transformation benötigen.

2Domain-Driven Design

Domain-Driven Design (DDD) ist eine Sicht auf Softwareentwicklung, die die Fachlichkeit ins Zentrum stellt – und zwar nicht nur bei der Anforderungsermittlung durch die Business-Analystin, sondern insbesondere auch bei der Modellierung und Programmierung.

Sprache, Ereignisse, Handlungen, Arbeitsmittel und Strukturen der Domäne werden bewusst in die Software übertragen, damit die Anwenderinnen die bestmögliche Unterstützung für ihre Arbeit bekommen.

2.1DDD-Konzepte gegen Komplexität

Domain-Driven Design kann uns dabei helfen, die akzidentelle Komplexität bei Neuentwicklung zu vermeiden, aber – und das ist das Thema dieses Buches – insbesondere auch die Komplexität von Legacy-Systemen zu verringern.

In Abbildung 2–1 sind die verschiedenen Konzepte aus DDD aufgeführt, die uns helfen, die Komplexität im Problem- und im Lösungsraum auf den essenziellen Anteil zu reduzieren. DDD hilft uns also dabei, von der rechten Spalte, der akzidentellen Komplexität, zurück zur linken Spalte, der essenziellen Komplexität, zu gelangen.

Abb. 2–1Komplexität und DDD

Im Folgenden werden wir die einzelnen Konzepte und Methoden von DDD mit Blick auf Legacy-Software erklären. Wem diese Konzepte und Methoden bereits geläufig sind, dem empfehlen wir nach einem Blick auf das direkt folgende Beispiel einen Sprung zu Kapitel 3, wo es um die Erweiterung von DDD um Methoden für die Anforderungsermittlung gehen wird.

Ein erstes Beispiel: Bestandssoftware im Kino

Als Beispieldomäne nehmen wir ein bisher unabhängiges Programmkino namens Metropolis, wie es in manchen Städten noch existiert. In diesem Programmkino wird für die Planung der Vorstellungen und für den Verkauf der Karten die Legacy-Software CineSmall eingesetzt (s. Abb. 2–2).

Abb. 2–2C4-Kontextsicht auf CineSmall. (Für mehr Informationen über die Notation des C4 Model siehe Abschnitt »Das C4 Model« zu Beginn von Teil I auf Seite 11.)

Bisher verläuft die Arbeit in unserem Programmkino folgendermaßen: Die Kinomanagerin arbeitet jede Woche an der Erstellung eines neuen Wochenplans mit allen Filmen, die in der nächsten Woche gezeigt werden sollen. Solch ein Wochenplan wird immer am Donnerstag herausgegeben und ab der Freigabe in CineSmall können dann Karten für die Vorstellungen der neuen Kinowoche verkauft werden. Der Verkauf der Kinokarten wird von der Kassenmitarbeiterin direkt im Kino durchgeführt. CineSmall bietet ihr dafür Saalpläne für alle Vorstellungen, wo sie für die Kinobesucherinnen Plätze reservieren und Tickets verkaufen kann.

Leider kann unser Programmkino nicht mehr wirtschaftlich arbeiten und die Eignerin muss es an eine große Kinokette verkaufen. Diese Kinokette hat aktuell eine Standardsoftware im Einsatz, die mehr schlecht als recht an die Prozesse der Kinokette angepasst wurde.

Bei der Due-Diligence-Prüfung vor der Übernahme des Programmkinos hat das Management der Kinokette festgestellt, dass CineSmall von seiner Funktionalität her gut zu den Prozessen der Kinokette passen würde. Um das Unternehmen weiterzuentwickeln, beschließt das Management, dass die Kette und weitere dazugekaufte Kinos auf CineSmall umsteigen sollen. Zum Teil sind diese Kinos größer als das Programmkino und zeigen statt Arthouse-Filmen eher Mainstream-Filme.

Diesen Anpassungen ist CineSmall in seiner aktuellen Architektur nicht gewachsen. Die hinzugezogenen technischen Beraterinnen empfehlen dem Management, CineSmall in eine Microservices-Architektur (vgl. Abschnitt 4.5) umbauen zu lassen, damit sowohl Skalierungsanforderungen als auch zusätzliche Funktionalitäten, wie Kinokartenkauf im Web, möglich werden. Um die Architektur von CineSmall auf neue Beine zu stellen, schlagen die Beraterinnen eine Analyse mit Domain-Driven Design vor.

Schauen wir uns die Empfehlungen der Beraterinnen einmal im Detail an!

2.2DDD und die Fachdomäne

Damit Entwicklerinnen eine Software umbauen können, müssen sie die Domäne verstehen – denn in der Software kann nur das richtig umgesetzt werden, was die Entwicklerinnen verstanden haben (s. [Brandolini 2021]). Dieser Lernprozess über die Domäne findet am schnellsten statt, wenn die Entwicklerinnen direkt von den Fachexpertinnen der Domäne lernen können.

Um umfassend zu lernen, benötigen die Entwicklerinnen eine Gruppe von Fachexpertinnen, die unterschiedliche Aufgaben mit dem Softwaresystem oder auch weiteren Systemen durchführen. Nur wenn man alle bzw. einen Großteil der Aufgaben versteht und ihren Zusammenhang kennt, wird der Problemraum, für den die Software gebaut wurde, in seiner Gesamtheit sichtbar.

Eine weitere gute Ansprechpartnerin sollte auch die Product Ownerin sein, die über die Weiterentwicklung und Ausgestaltung ihres Softwaresystems von der fachlichen Seite aus wacht. Bei den Product Ownerinnen kann man meistens die Frage klären, wozu die Software gut ist. Also wie sie zum Erfolg des Unternehmens beiträgt.

Bei unserem kleinen Programmkino mit dem Legacy-System CineSmall stehen uns als Fachanwenderinnen das Kinomanagement und ein oder zwei Kassenmitarbeiterinnen zur Verfügung. Eine echte Product Ownerin gibt es in diesem Fall nicht (mehr), denn die Software wurde vor Jahren