By

Kim Moerke

22
Apr

„Mit DDD kommt man schnell von einer konzeptionellen Diskussion in den Code“

Wir wollen uns über zeitgemäße Software-Architektur unterhalten. Wenn wir zunächst einmal beim Wort „zeitgemäß“ bleiben: Was macht eine zeitgemäße Architektur aus?

Matthias Bohlen: Zeitgemäß heißt für mich zwei Dinge: einerseits nach den heute geltenden Qualitätsanforderungen des Vorhabens (also des Projekts oder Produkts), andererseits auch zeitgemäß im Sinne von “nach den aktuellen Regeln der Kunst”. Vorhaben beginnen, indem ein Team mit seinen Stakeholdern eine gewisse Einschätzung der benötigten Qualitäten hat, also „wie performant, wie sicher, wie benutzbar, wie wartbar, wie portabel, skalierbar, usw. muss das Ganze denn werden?“.

Diese Einschätzung ändert sich laufend. Beispiel: Jemand findet, die Anwendung sei nicht performant genug und baut deshalb einen Cache ein. Nach zwei Wochen beschweren sich die ersten Benutzer, dass die angezeigten Daten nicht mehr wirklich aktuell sind (Programmierfehler oder ein Missverständnis beim Einbau des Caches?). Dann könnte das Team auf die Idee kommen, lieber verständlichen, wartbaren Code zu wollen anstatt eine so hohe Performance, die man ja vielleicht auch auf andere Weise erreichen könnte, und sie bauen den Cache eben wieder aus.

Ein anderes Beispiel wäre die Anbindung mobiler Geräte. Die Architektur muss sich dann manchmal verändern und für die kleinen Geräte extra Backends anbieten, damit es die Frontends nicht so schwer haben.

Der andere Aspekt, den ich genannt hatte (Entwerfen nach den aktuellen Regeln der Kunst) verändert sich auch ständig: Eine Zeit lang wollten viele Teams Microservices machen, weil das auf sämtlichen IT-Konferenzen diskutiert wurde. Mittlerweile hat man gesehen, welche Komplexität das mit sich bringt, und Teams fragen sich eben heute: Müssen wir denn unbedingt ein so feingranulares Deployment haben, wie es Microservices anbieten? Reichen nicht etwas größere Subsysteme aus, mit Schnittstellen, die dadurch wesentlich leichter zu handhaben sind als die von Microservices?

Dasselbe gilt für fortgeschrittene Konzepte wie CQRS, Event Sourcing, Event-driven, usw. In meinen Trainings zeige ich, dass man das nicht großflächig als Architektur einführen muss, sondern auch lokal entscheiden kann, an welcher Stelle im System man CQRS/ES einsetzt, und an welcher Stelle eher klassische Zustandshaltung. Und ob man nun unbedingt alles “Event-driven” machen muss, ist auch nicht selbstverständlich, sondern situationsabhängig.

Welche Herausforderungen an Software-Architekturen sind in den letzten Jahren neu hinzugekommen?

Matthias Bohlen: Mobile Geräte sind ja nun schon lange da, doch für Enterprises sind sie immer noch herausfordernd. Die Denkweise: “Lieber einen kleinen Use Case richtig mobilisieren, als eine große Anwendung auf das Mobildings zu bringen”, hat sich noch nicht wirklich durchgesetzt. Das bewirkt Usability-Probleme ohne Ende.

Beispiel: Die aktuellen Sicherheitsanforderungen im Banken-Umfeld gehen mir als Anwender mehr und mehr auf die Nerven. Manche Banken investieren zu wenig darin, die Anwender zu beobachten und wundern sich, warum die Kunden zu “moderneren Banken” oder zu Apple Pay abwandern. Beispiel: Ich will eine Überweisung machen. Meine Bank bietet mir dafür eine mobile App und zusätzlich eine zweite App, mit der ich TANs generieren muss, die ich dann mühsam in die erste App abtippen muss, um die Überweisung abzuschließen. Man glaubt nicht, dass wir im Jahr 2021 leben.

Weitere Challenge: Die Passwörter. Ich habe einen Passwort-Manager, in dem ich pro Bank drei Passwörter halten muss: eins für die Banking App, eins für die TAN-App, eins für die Spezial-App, die nur dann in Aktion tritt, wenn ich mit Kreditkarte zahle, nicht bei Überweisungen. Haben wir tatsächlich 2021?

Der Konflikt “Benutzbarkeit versus Sicherheit” wird traditionelle Unternehmen immer stärker beschäftigen, weil sie von kleinen, innovativen Unternehmen rechts überholt werden. Die Kleinen haben diesen Konflikt anerkannt, tiefgehend verstanden und dann konsequent gelöst.

[marketing_widget_area 8]

Architektur-Trend Domain-driven Design

Auf dem DDD Camp geht es konzentriert um Domain-driven Design. Was findest du persönlich spannend daran?

Matthias Bohlen: Für mich ist spannend, wie eine zusammengewürfelte Truppe von Leuten gemeinsam per DDD in einem kurzen Hackathon von drei Tagen eine Anwendung aus dem Boden stampft, die wirklich etwas Sinnvolles tut. Die Teilnehmer:innen nutzen DDD, um schnell von einer konzeptionellen Diskussion des Themas in den Code zu kommen – das finde ich faszinierend!

Die Leute haben im Camp gesehen, wie einfach es eigentlich sein könnte und werden dann versuchen, es im Alltag ähnlich gut hinzubekommen.

Sie werden gut mit den Fachleuten zusammenarbeiten und sich im Team Regeln geben, wie Domänenbausteine umzusetzen sind, damit sie in der eigenen Firma eben die Ideen auch schnell vom letzten Meeting in den Code bringen, um frühzeitig Feedback zu bekommen und dann mit hoher Qualität die Sache zu Ende zu entwickeln.

Die Leute im Camp erleben auch, wie DDD mit seinen Standardbausteinen die Team-Zusammenarbeit verbessern kann. Beispiel: Ein Paar schnappt sich ein Aggregate zur Umsetzung, ein anderes Paar nimmt sich ein weiteres Aggregate, jeweils mit einem Service oben drüber und einem Repo unten drunter. Das geht nach kurzer Übungszeit wie der Blitz und sorgt für klare Verantwortung in der Teamarbeit!

Welcher Trend der Software-Architektur – abgesehen von DDD – wird deiner Einschätzung nach im Jahr 2021 Fahrt aufnehmen?

Matthias Bohlen: “Voraussagen sind schwierig, besonders wenn sie die Zukunft betreffen”, das sollen sowohl Karl Valentin als auch Nils Bohr gesagt haben. 🙂

Wenn ich mal in die Glaskugel schaue, dann sehe ich, dass Corona noch eine Weile bei uns bleiben wird und deshalb das Thema Remote-Zusammenarbeit weiter stark im Kommen sein wird. Auch wenn Corona eines Tages besiegt sein sollte, werden die Unternehmen nicht einfach zur Präsenzarbeit zurückkehren wie vorher.

Das bedeutet, die Softwaresysteme müssen Kollaboration aus der Ferne besser unterstützen. Die Use Cases werden sich genau in diese Richtung verändern, und die Architekturen müssen sich anpassen, indem sie weniger zentralistisch gestaltet sein müssen.

Beispiel: Eine Person sollte selbst flexibel entscheiden können, für welche Firma sie heute von 11–13 Uhr arbeitet und dann von 15–17 Uhr vielleicht für eine andere Firma. Versuch das einmal mit Microsoft Teams zu lösen: Du wirst feststellen, dass der MS-Teams-Admin der Firma 1 es seinen Leuten verbieten kann, sich später in eine Videokonferenz von Firma 2 einzuwählen. Fehlermeldung in MS Teams: “You cannot get there from here!”. Was Corona uns gezeigt hat: Es gibt ab jetzt eben kein “there” und kein “here” mehr – das ist vorbei, aus!

Ich bezweifle aber, dass das in 2021 bei den Großunternehmen Traktion bekommt, dafür sind sie einfach zu langsam. Auch hier besteht die Gefahr, von den kleineren, innovativeren Unternehmen rechts überholt zu werden. Für die Kleinen und Mittelgroßen ist das wunderbar, es eröffnen sich völlig neue Chancen!

Für uns Softwarearchitekten heißt das, wir müssen unsere Köpfe flexibler machen, damit unsere Architekturen flexibler werden.

Welches Architektur-Thema abseits der Hypes und Trends sollte deiner Meinung nach eine größere Beachtung finden?

Matthias Bohlen: Systematisierung der Prozesse in den Teams: Wenn Du als Entwickler ein System hinter dem hast, was Du tust, dann brauchst Du nicht jedesmal nachzudenken, wie Du etwas löst. Du kannst vieles wiederholbar machen, z.B. Autorisierung, Validierung, API-Gestaltung, Speicherung, optische Darstellung im Frontend, usw.

Warum sollte ein Entwickler z.B. immer wieder darüber nachdenken, wie man das UI macht? Ein System muss her: grobe Navigation links, feine Navigation oben, dann eine Liste, aus der man einen Eintrag anwählt, zu dem dann die Details dargestellt werden. Mit dem Back-Button des Browsers einfach zurück zur Liste, und fertig!

Die Benutzer fühlen sich wohler, und die Entwickler haben weniger Arbeit, wenn solche Dinge in einem Design-System festgehalten sind, das durch Fertigkomponenten in Front- und Backend unterstützt wird.

Das Backend braucht eine gewisse Architektur, damit es diese Fertigkomponenten des UIs versorgen kann. Diese “Fertigteile-Architektur” muss man möglichst schnell anstreben, um sich auf die kreative, Werkstatt-artige Arbeit mit den Domänenexperten konzentrieren zu können. Dann macht das gemeinsame Entwickeln mit Fach- und IT-Seite so richtig Spaß, sowohl technisch als auch finanziell.

Vielen Dank für dieses Interview!

Matthias Bohlen ist Experte für effektive Produktentwicklung. Er hat als Coach, Consultant und Trainer für Entwicklungsorganisationen aus den Branchen Energie, Touristik, Logistik, Automotive, Telekom, Versicherungen und Gesundheitswesen gearbeitet. Matthias Bohlen hilft Führungskräften und Teams, ihre Performance zu verbessern, Ziele zu erreichen und die Zufriedenheit von Kunden und Mitarbeitern gleichermaßen zu erhöhen.
12
Mrz

Warum spricht jeder über DDD?

Domain-driven Java

Microservices sind in aller Munde. Mit diesem Architekturstil werden uns bessere Wartbarkeit, kürzere Time to Market, einfachere Skalierbarkeit und alle sonst noch denkbaren Verbesserungen für die Softwareentwicklung versprochen. Zunächst wurden Microservices vor allem als technisches Thema verstanden. Um ein modernes verteiltes System zu bauen, braucht es schließlich die Beherrschung verschiedenster Technologien. Schnell wurde allerdings klar, dass für eine tragfähige Microservices-Architektur ein guter Schnitt nötig ist und dass ein guter Schnitt nur einer sein kann, der auf der Fachlichkeit basiert. Dadurch wurde ein Thema ins Rampenlicht geholt, das vorher (zu Unrecht) nur einer kleinen Gruppe von Experten bekannt war – Domain-driven Design oder kurz DDD.

„Fokussiere Dich auf die Fachlichkeit deiner Software, verstehe zunächst das Problem, bevor du mit einer Lösung durch die Tür kommst.“ Das ist die grundlegende Lehre von DDD. Um die Fachlichkeit zu lernen, brauchen wir Kommunikation mit den Fachexperten. Schauen wir uns an einem Beispiel an, was das konkret bedeutet.

Beispieldomäne

Unser Beispiel liegt in der Domäne „Bankwesen“: Ein Kunde geht zur Bank und eröffnet ein Girokonto. Dann zahlt er einen Betrag von 100 € ein und überweist diesen auf das Konto eines anderen Kunden. Am Ende des Jahres berechnet ein Bankmitarbeiter den Jahreszins für das Konto und zahlt ihn auf das Konto ein.

Die Geschichte der Domäne stellt man gerne in einer sogenannten Domain Story (Kasten: „Domain Storytelling“) dar. Hierbei wird das, was in der Domäne passiert, in einem Diagramm dargestellt. Um die Domain Story zu lesen, gilt es, den Sequenznummern zu folgen (Abb. 1).

Abb. 1: Unsere Domain Story

Domain Storytelling

Domain Stories sind eine einfache grafische Notation und stammen aus dem Domain Storytelling [1], [2]. Es gibt zwei Arten von Icons und eine Art von Pfeil:

  • Actor – die handelnden Personen

  • Work Object – die Arbeitsgegenstände, mit denen etwas getan wird

  • Activity – die Handlungen, die die Akteure an den Arbeitsgegenständen vornehmen

Domain Stories entstehen, indem wir uns von den Fachexperten erzählen lassen, was in der Domäne geschieht. Während der Erzählung wird die Geschichte so, wie wir sie verstehen, aufgezeichnet. So geben wir direkte Rückmeldung über das Verständnis, und mögliche Missverständnisse werden schnell aufgeklärt.

Lösungsversuch

Jeder von uns kennt diese Geschichte, aber wie baut man eine Software dafür? Wie würde das typische Entwicklungsteam an diese Aufgabe herangehen? Das Team aus Technikern beantwortet zuerst die (scheinbar) wichtigsten Fragen: Welche Programmiersprache? Wie schaffen wir es, die neuesten Frameworks/Versionen zu verwenden? Können wir statt einer klassischen relationalen DB modernes NoSQL einsetzen?

Moment mal! Haben diese Fragen irgendetwas mit der Bank und Konten zu tun? Hat uns ihre Beantwortung näher an unser Ziel gebracht? Fühlt sich nicht so an. Was ist denn überhaupt unser Ziel?

Leider ist das Ziel nicht technische Schönheit. Das Ziel ist es, den Anwenderinnen und Anwendern in ihrer Domäne zu helfen; sie bei ihrer Arbeit zu unterstützen; diese Arbeit leichter, schneller, effizienter zu machen. Wenn wir das mit Software schaffen – super! Deshalb sagt Domain-driven Design: Baue die Software so, dass sie in der Domäne tief verwurzelt ist. Baue sie als Reflektion der Domäne. Damit wir die Domäne in Software reflektieren können, müssen wir sie verstehen. Mit diesem Verständnis entwickeln wir ein Modell und implementieren es – das sogenannte Domänenmodell.

Ubiquitous Language

Damit die Entwickler das Domänenmodell bauen können, müssen sie mit den Fachexperten über die Domäne sprechen können – deshalb brauchen wir eine gemeinsame Sprache für Entwickler und Fachexperten. Die Entwickler haben eine technische Sprache. Sie reden über Klassen, Methoden und Interfaces. Auch für sie spielen Konten eine Rolle, aber wenn wir sagen: „Ich logge mich in mein Konto ein“, geht es uns nicht um das Girokonto aus der Bankgeschichte. Diese technische Sprache ist wichtig, allerdings nicht besonders gut geeignet, um über die Domäne zu kommunizieren. Die Domänenexperten haben ihre eigene Fachsprache. In der Bank sprechen wir z. B. über Girokonto, Geldbetrag, Währung, einzahlen, überweisen usw.

DDD sagt, dass wir eine gemeinsame Sprache für Fachexperten und Entwickler haben wollen, um Sprachverwirrung zu vermeiden. Sie soll auf der Fachsprache basieren und überall verwendet werden. Überall bedeutet im Gesprochenen, im Geschriebenen, in Diagrammen und eben auch im Code. Diese Sprache wird deshalb Ubiquitous Language (also allgegenwärtige Sprache) genannt. Wenn wir die Domain Story aus unserem Beispiel anschauen, sehen wir ausschließlich Fachwörter und keine technischen Wörter. Das ist gut so, wir haben uns also wirklich auf die Fachlichkeit fokussiert. Alle diese Wörter sind Kandidaten dafür, auch Wörter der Ubiquitous Language zu werden.

DDD im Kleinen

DDD gibt uns Konstruktionsanleitungen für Domänenmodelle und zwar im Großen und Kleinen. Im Kleinen betrachten wir, welche Arbeitsgegenstände unsere Fachexperten verwenden und, noch wichtiger, was sie damit tun, wie sie damit umgehen. Auch hier lassen wir uns also von der Domäne treiben. Aus den Gegenständen werden Klassen. Aus den Umgangsformen werden Methoden.

Was heißt das in unserem Beispiel? Ein zentraler Gegenstand im Bankwesen ist das Girokonto. Also implementieren wir eine entsprechende Klasse Girokonto in unser Domänenmodell. Was wird mit einem Girokonto getan? Beispielsweise wird ein Betrag eingezahlt und Jahreszinsen werden berechnet. Deshalb bekommt die Klasse Girokonto entsprechende Methoden. In Abbildung 2 sieht man, wie aus einer Domain Story das Domänenmodell abgeleitet werden kann. Als zusätzliche Klasse kommt noch Betrag dazu. In Java würde daraus folgender Code entstehen:

public class Girokonto { public void zahleEin(Betrag betrag) //... }
Abb. 2: Aus der Domain Story wird das Domänenmodell abgeleitet

Darin steckt eine ganze Menge Ubiquitous Language: Die Wörter „Girokonto“, „einzahlen“, „Betrag“ stammen alle aus der Fachsprache. Es ist ein ausdrucksstarkes Domänenmodell mit reichem fachlichem Verhalten („domain model with rich behaviour“). Nicht nur die Klasse, auch die Methoden haben einen fachlichen Namen.

In der Praxis trifft man oft auf das Gegenteil, das sogenannte Anemic Domain Model. Dieses hat zwar fachliche Klassen, aber diese haben kein fachliches Verhalten. Bei dem Girokonto würde man aus technischer Sicht z. B. denken, dass alles, was wir damit machen können, am Ende ja immer den Kontostand ändert. Also ist eine mögliche anämische Implementierung die folgende:

public class Girokonto { public void setKontostand(Betrag kontostand)  //... }

Man erkennt anämische Domänenmodelle daran, dass ihre fachlichen Klassen hauptsächlich aus Gettern und Settern bestehen. Hier ist jeder fachliche Umgang verloren. Das Modell ist nicht mehr so ausdrucksmächtig. Außerdem kann so nicht mehr sichergestellt werden, dass nur fachlich sinnvolle und valide Operationen ausgeführt werden. „Kontostand setzen“ ist nicht das, was man mit einem Girokonto machen kann – Konten bekommen nicht auf einmal einen beliebigen Kontostand. Das wird noch klarer sichtbar, wenn wir uns das Abheben anschauen. Das ist in der Fachlichkeit nur möglich, wenn das Konto gedeckt ist. Im anämischen Modell wird die Deckung nicht geprüft und das Konto kann illegal überzogen werden. Im sauberen Domänenmodell wird auch sauber geprüft und Überziehen so unmöglich gemacht (Listing 1).

Listing 1

public class Girokonto { public void zahleEin(Betrag betrag) // ... public boolean isGedecktMit(Betrag betrag)  // ... public void hebeAb(Betrag betrag) { if (!isGedecktMit(betrag)) { throw new Exception("Vorbedingung verletzt"); } // ... } }

So können die Klassen des Domänenmodells sicherstellen, dass ihre Instanzen immer einen validen Zustand haben. Das Entwerfen des Domänenmodells nennt DDD auch taktisches Design. Weitere Informationen dazu findet man z. B. unter [3].

Ein reiches Domänenmodell ist etwas Großartiges. Problematisch ist, dass es immer weiterwächst. In unserem Beispiel kommen für die Klasse Girokonto noch die Methoden berechneJahreszins() und ueberweise() hinzu, und wir haben ja bisher nur ein kleines Stück der Domäne modelliert. Irgendwann wird das Modell so groß sein, dass es nicht mehr im Ganzen zu verstehen und deshalb fehleranfällig ist. DDD im Kleinen mit taktischem Design reicht also nicht aus, wir brauchen auch noch strategisches Design – DDD im Großen.

DDD im Großen – die Domäne aufteilen

Je kleiner ein Modell ist, desto einfacher kann es verstanden werden. Das strategische Design von DDD sagt uns deshalb, dass wir nicht nur ein, sondern mehrere Domänenmodelle bauen sollen. Jedes dieser Modelle existiert in einem eigenen Kontext und ist klar von den anderen Modellen abgegrenzt (bounded). Deshalb spricht man hier von Bounded Context. Das einzelne Modell bildet dann nur diejenigen Eigenschaften des Realweltgegenstands ab, die im jeweiligen Kontext wesentlich sind. Die Domäne wird so in unterschiedliche Bounded Contexts aufgeteilt. Dabei suchen wir nach Bereichen, in denen Unterschiedliches getan wird (Abb. 3).

Abb. 3: Aufteilung in Bounded Contexts

Es haben sich also die drei Bounded Contexts Kontoeröffnung, Kontoführung und Zinsberechnung herauskristallisiert. Mit diesen Kontexten kann man eine sogenannte Context Map zeichnen. In ihr finden sich die Kontexte und die Beziehungen dazwischen wieder. Jeder Kontext ist dann auch Kandidat für einen Microservice (Abb. 4).

Abb. 4: Context Map

Ubiquitous Language und Modell hängen eng zusammen. Bei genauem Hinsehen erkennt man, dass jedes Modell (d. h. jeder Bounded Context) sogar seine eigene Ubiquitous Language hat. Oben haben wir gesagt, dass wir mehrere unterschiedliche Domänenmodelle bilden. Das heißt, wir bilden denselben Gegenstand aus der Wirklichkeit mit unterschiedlichen Klassen ab. Unterschiedliche Klassen mit demselben Namen. Daran muss man sich erst einmal gewöhnen! Unsere Beispielmodelle sehen dann wie in Abbildung 5 aus.

Abb. 5: Beispielmodelle

Bounded Contexts müssen nicht gleich als Microservices implementiert werden. In Java kann man die unterschiedlichen Kontexte auch mit Packages oder (ab Version 9) mit Modules ausdrücken. Hier hätte man dann also zwei Packages oder Module de.bank.kontofuehrung und de.bank.zinsberechnung, die jeweils eine Klasse Girokonto enthalten.

Erste Schritte

Wie führe ich DDD nun in meinem eigenen Projekt ein? Auf der grünen Wiese ist das natürlich leichter als in einem bestehenden Projekt, das vielleicht eine über viele Jahre gewachsene Legacy-Anwendung betreut. Aber auch im zweiten Fall ist es möglich, die Vorteile zu realisieren. In einem neuen Projekt empfiehlt es sich, zunächst grob die Domäne im Ganzen zu modellieren und daraus den Domänenschnitt abzuleiten. Hierzu eignet sich Big Picture Event Storming oder Coarse-grained Domain Storytelling. Als Ergebnis bilden wir eine Context Map.

Als Nächstes schauen wir nun in den jeweiligen Bounded Context hinein und modellieren, was dort im Detail vor sich geht. Hieraus leiten wir das Domänenmodell für diesen Kontext ab. Das Domänenmodell wird in der angemessenen Technologie und Programmiersprache implementiert. Auch hier bieten sich wieder Event Storming und Domain Storytelling an; nun aber in den Varianten Detaillevel bzw. Fine-grained.

Um im Brownfield DDD einzuführen, ist es sinnvoll, in mehreren Schritten vorzugehen. Das System wird nicht von einem Tag auf den anderen durch Wunderheilung zu einem Ideal.

  1. Domänenmodellierung und Domänenschnitt, wie wenn man sich auf der grünen Wiese befände, d. h., Entwicklung der Soll-Architektur

  2. Analyse der Ist-Architektur; das kann händisch oder toolgestützt erfolgen

  3. Übereinanderlegen von Ist- und Soll-Architektur: An welchen Stellen kann das Altsystem in Richtung der gewünschten neuen Struktur bewegt werden?

  4. Herauslösen eines ersten Bounded Context aus dem Big Ball of Mud (d. h. dem komplex verwobenem Softwaremonolithen); beim ersten Mal bietet es sich an, einen weniger wichtigen auszuwählen, also eine Supporting oder Generic Subdomain – hieran wollen wir lernen

  5. Herauslösen der (ersten) Core Domain – hiermit wollen wir jetzt wirklich Nutzen erzielen

Im Text ist dieses Vorgehen schnell beschrieben, im richtigen Leben kann es natürlich komplex werden. Trotzdem lohnt es sich in den meisten Fällen, diesen Weg zu gehen. Das liegt daran, dass Altsysteme, also unsere Big Balls of Mud, typischerweise too big to fail sind. Sie sind so groß, dass ein kompletter Neubau Jahre dauern würde. Diese Zeit ist zu lang, als dass man das Altsystem im gleichen Zustand belassen könnte. Stattdessen entwickelt man es weiter. Das Neusystem kommt also gar nicht hinterher. Deshalb empfiehlt sich das hier beschriebene kleinschrittige Vorgehen, bei dem das Altsystem nicht durch ein Neusystem ersetzt wird, sondern sich das Altsystem in das Neusystem verwandelt und weiterentwickelt.

Das kann auch bei Technologie- und sogar bei Programmiersprachenwechseln funktionieren. So werden auch alte Mainframesysteme, die in COBOL implementiert sind, in eine modernere Programmiersprache migriert und in die Cloud verschoben. Auch dabei wird schrittweise, d. h. Kontext für Kontext, migriert. Wichtig dabei: Das Ziel ist nicht unbedingt die vollständige Migration, sondern das Erhalten (bzw. Wiederherstellen) der Zukunftsfähigkeit. Meist entsteht dann ein Mischsystem, in dem einzelne Bounded Contexts in der neuen Welt, andere in der alten Welt implementiert sind. Evolution kann eben nur schrittweise stattfinden, wobei jeder Schritt eine lebensfähige Version des Systems ist.

Fazit und Ausblick

Domain-driven Design ist eine großartiges Denk- und Entwurfswerkzeugkiste, um Programmiererinnen und alle anderen, die an Softwareentwicklung arbeiten, auf das zu fokussieren, was wirklich wichtig ist: die Fachlichkeit. Wichtige Werkzeuge sind Strategic Design, Ubiquitous Language und Tactical Design. Das hilft uns insbesondere in der modernen Welt, in der unsere Systeme schnell anpassbar, Cloud-fähig und idealerweise als Microservices implementiert sein sollen.

In einem Überblicksartikel wie diesem kann man das Thema nur an der Oberfläche ankratzen. Wer sich tiefer einlesen will, aber nicht viel Zeit hat, dem sei „Domain-Driven Design kompakt“ [4] von Vaughn Vernon empfohlen. Wer sehen will, wie DDD in der Praxis umgesetzt wird, findet mit dem LeasingNinja [5] ein konkretes Beispiel. Anhand der Domäne Leasing wird hier exemplarisch gezeigt, wie man von der Fachlichkeit über Domain Stories, Context Map und taktisches Design bis in die Implementierung in Code kommt.

Henning Schwentner

 

Henning Schwentner liebt Programmieren in hoher Qualität. Diese Leidenschaft lebt er als Coder, Coach und Consultant bei der WPS – Workplace Solutions aus. Dort hilft er Teams dabei, ihre gewachsenen Monolithen zu strukturieren oder neue Systeme von Anfang an mit einer tragfähigen Architektur zu errichten. Häufig kommen dann Microservices oder Self-contained Systems heraus.

30
Sep

Domain-driven Design: Warum jetzt die Zeit für DDD gekommen ist

Domain-driven Design liegt im Trend – und das über 15 Jahre nach dem Erscheinen des gleichnamigen Buches von Eric Evans. Warum erlebt DDD gerade jetzt einen Aufschwung?

DDD hilft uns nicht nur beim Softwareschnitt, sondern auch beim Teamschnitt.

Matthias Bohlen: Die Zeit für DDD ist aus vielen Gründen jetzt gekommen. Ich nenne mal nur zwei davon: Die Komplexität der Systementwicklung und das Bedürfnis nach agilen, schlagkräftigen Teams, die nicht ständig aufeinander zu warten brauchen.

Einerseits ist mittlerweile unsere Art, Systeme zu entwickeln, so komplex geworden, dass sich eine falsche fachliche Aufteilung des Systems noch schwerer beheben lässt als früher. Denke z.B. an Microservices, die in Containern ablaufen, die auf geeigneter Infrastruktur orchestriert werden. Den Schnitt dieser Services ändert man halt nicht mehr “mal eben schnell”. DDD kann Teams dabei helfen, Systeme entlang der Bounded Contexts fachlich sinnvoll zu schneiden, so dass dieser Schnitt nicht so oft geändert zu werden braucht. Die Fachlichkeit einer Versicherung (Risiko, Produkt, Vertrag, Prämie, Schaden, Leistung zum Beispiel) ist seit 150 Jahren dieselbe, selbst wenn es angeblich demnächst Peer-to-peer-Versicherungen in der Blockchain geben soll.

Der andere Grund, warum DDD so aktuell wird, sind agile, selbstständige Teams. DDD optimiert die Kommunikation zwischen Domänenexperten und IT-Leuten. Und: DDD hilft uns nicht nur beim Softwareschnitt, sondern auch beim Teamschnitt. Wenn Teams jeweils nur kleine Modelle, also einen geschickt gewählten Ausschnitt der Fachdomäne, bearbeiten, dann brauchen sie nicht ständig auf das Ergebnis des Nachbarteams zu warten, sondern können vorwärts laufen. Würden wir auch noch die Domänenexperten mit in die Cross-funktionalen Teams setzen, dann würde DDD noch viel mehr Spaß machen, als es das heute schon tut.

Was ist für dich der Hauptgrund, sich mit DDD zu beschäftigen?

Matthias Bohlen: Besonders reizvoll ist für mich die konsequente Durchgängigkeit der DDD-Methodik, von den ersten Meetings zwischen Domänenexperten und Entwicklern, über das strategische Design, bis hin zum Anwendungscode, der aus den immer gleichen neun DDD-Grundbausteinen zusammengebaut werden kann. Im DDD-Camp, das Anfang Dezember stattfindet, gehen wir in Kleingruppen einmal komplett durch diesen Prozess, bis hin zur lauffähigen Cloud-Anwendung, die wir am Schluss benutzen und feiern können.

Bei DDD arbeiten Domänenexperten und Software-Entwickler eng zusammen. Ist DDD eher ein methodisches Konzept oder ein technologischer Lösungsansatz?

Matthias Bohlen: Eher methodisch, doch mit Berührung zur Technik. Mit den Domänenexpert/inn/en reden wir über Modell-Elemente wie Services, Aggregates, Entities, Value Objects, usw. Für diese Elemente hat jedes Team intern bereits vorher ein Mapping auf die Technik festgelegt. Da ist also vollkommen klar, wie z.B. ein Aggregate im Prinzip umgesetzt werden wird. Das bedeutet: Wenn du aus einem Fachmeeting kommst, kann das Team die besprochenen Modell-Elemente sofort im Code umsetzen, weil das Mapping auf den Code schon standardisiert ist. Dieses Mapping ist natürlich in jedem Team möglicherweise anders, denn es hängt von Architektur, Plattformen, Programmiersprachen und eingesetzten Frameworks ab. Daher entscheidet jedes Team selbst über dieses Mapping.

Auf dem DDD Camp vermittelst du Grundlagen des „taktischen” DDD. Was ist das?

Matthias Bohlen: Strategisches Design bedeutet, die eher längerfristig gültige Aufteilung des Systems und der Teams zu finden. Taktisches Design findet jeden Tag statt. Jedesmal, wenn ein Feature entworfen und programmiert werden soll, muss Fachlichkeit in Modell-Elemente (z.B. Events, Services, Aggregates, usw.) zerlegt werden, d.h. ich bekomme aus jeder mit den Fachexperten besprochenen User Story ein paar solcher Elemente. Die programmiere ich dann mit dem zuvor verabredeten Mapping, mache sie vorzeigbar und frage die Fachexperten, ob das prinzipiell so stimmt. Wenn ja, programmiere ich alles in hoher Qualität aus. Die „Taktik“ des DDD ist für mich dieser wöchentlich wiederholbare Zyklus aus Kommunikation, Modellierung, Umsetzen und Feedback.

DDD gilt als Methode zum Bauen von Microservices. Richtet sich das Camp also nur an Entwickler & Architekten von Microservices-Lösungen?

Die Ziel-Architektur braucht keine Microservices zu enthalten, um DDD sinnvoll zu machen.

Matthias Bohlen: Nein, die Ziel-Architektur braucht keine Microservices zu enthalten, um DDD sinnvoll zu machen. Es reicht, wenn die Fachlogik der Domäne genügend kompliziert ist. Für fachlich reichhaltige Domänen lohnt sich die Investition, DDD als Methode zu erlernen, sich Fachexperten zu suchen, sie mit Teams eng zusammenarbeiten und gemeinsam die Systeme entwerfen zu lassen. Egal, ob du einen Monolithen, Microservices, Components-and-Connectors oder Pipes-and-Filters als Architekturgrundlage hast: Sobald die Domäne schwierig genug wird und die Zahl der Missverständnisse zwischen Fachexperten und Entwicklern zunimmt, dann setze DDD ein.

Wie kann man sich dem Thema DDD am besten nähern? Welche ersten Schritte empfiehlst du?

Matthias Bohlen: Zuerst: Das Ganze steht und fällt mit den Fachexpert/inn/en. Du brauchst kundige Leute, die großes Wissen über die Prozesse und Daten in der Domäne haben. Diese Leute müssen auch Zeit haben und motiviert sein, mitzumachen. Sie sollten abstrahieren und die Domäne gut verständlich erklären können. Wenn ich in die Kalender von Fachexperten in typischen Unternehmen schaue, finde ich vor Ablauf von 6 Wochen manchmal schon gar keinen Termin für DDD-Gespräche. Hast du die Leute einmal gefunden, dann kannst du mit ihnen anfangen zu modellieren, also z.B. mit Hilfe von Event Storming oder Story-Telling ein gemeinsames Domänenverständnis erzeugen.

Auf der langen Wand des Event Stormings findet ihr dann möglicherweise die abgrenzbaren Kontexte, die euch helfen, das Modell auf mehrere Teams aufzuteilen. In einer Context Map könnt ihr das erfassen, näher beschreiben und dann Teams gründen, die dem entsprechen. In jedem Team sprecht ihr dann darüber, wie die wöchentliche Arbeit mit DDD aussehen soll, z.B. indem ihr den Fachgespräche-Rhythmus und das Mapping der neun Standardbausteine auf den Code festlegt. Und dann kann’s losgehen mit dem ersten Aggregate.

Was möchtest du den Teilnehmern des DDD Camp vermitteln? Was ist die Kernbotschaft?

Matthias Bohlen: Ich möchte für die Teilnehmer/inn/en den DDD-Weg von den allerersten Ideen bis zum ausführbaren Code erlebbar machen. In meinen DDD-Schulungen kam öfters das erste “Aha”-Erlebnis: “Matthias, jetzt haben wir ja ein Modell, das wir im Code tatsächlich sofort runterschreiben und ausprobieren könnten. Schade, dass die Schulung jetzt hier zu Ende ist.” Das brachte mich auf die Idee für das DDD Camp. Es fehlte der Schritt ins gemeinsame Tun: gemeinsam eine Cloud App zu bauen, mit Hilfe der Methoden, die uns DDD in die Hand gibt. Genau das gehen wir im Dezember jetzt an. Ich freue mich schon darauf.

Vielen Dank für dieses Interview!

Geschrieben von: Hartmut Schlosser

Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. #java #eclipse #devops #machinelearning #seo. Zum Lächeln bringen ihn kreative Aktionen, die den Leser bewegen. @hschlosser