Hochwertige Software durch Domain Driven Design – Teil 1

“Das Problem zu erkennen, ist wichtiger, als die Lösung zu erkennen, denn die genaue Darstellung des Problems führt zur Lösung”. Albert Einstein

Domain-Driven Design (DDD) ist ein Ansatz für die Entwicklung von Software, bei dem die Schaffung einer gemeinsamen Sprache zwischen Domänenexpert:innen (also den Fachexpert:innen) und Systementwickle:innen im Vordergrund steht. Zwei grundlegende Konzepte von DDD sind: “Use a Ubiquitous Language” und “Make The Implicit Explicit”. Hierbei geht es darum, eine gemeinsame, durchgängige Sprache zwischen Entwicklern und Fachexperten zu etablieren. Diese Sprache wird in der Codebasis sowie in Dokumentationen verwendet, um sicherzustellen, dass alle Beteiligten die gleichen Begriffe für die gleichen Konzepte verwenden. „Make The Implicit Explicit“ zielt darauf ab implizite Annahmen und Informationen in der Softwareentwicklung klar und deutlich zu machen, um Missverständnisse zu vermeiden und eine präzisere Umsetzung zu ermöglichen. 

Insgesamt bietet DDD einen Rahmen für eine präzisere, leichter verständliche und anpassungsfähige Softwareentwicklung. Insbesondere bei größeren Software-Projekten, kann dies einen wertvollen Einfluss auf den Erfolg und die Qualität des Vorhabens haben.

Einführung

In diesem Beitrag geht es im Weitesten um das Lösen von Problemen durch geschickte Modellbildung. Konkret geht es darum, wie man Modelle erstellt, die die unbekannte, aber reale Welt repräsentieren. Sie werden erfahren, welche drei Qualitätskriterium dabei insbesondere sichergestellt werden müssen und wie dies geschehen kann. Speziell fokussieren wir uns dabei auf die Modellierung von Software, insbesondere im Kontext von Shop-Software. 

Sie haben sicher schon von DDD gehört, denn zum einen gibt es die Methode bereits seit 2004, und zum anderen erfährt sie derzeit hohe Aufmerksamkeit im Rahmen der Paradigmen von Microservices und Composable Commerce. Denn die Kernidee von DDD, ‘machen Sie das Implizite explizit’, passt besonders gut zur gelungenen Auseinanderhaltung von Subsystemen.  

Es werden Ihnen in diesem Beitrag zwei prägnante Dinge zu DDD auffallen: Zum einen ist die Methode komplex und unscharf per se, aber auf der anderen Seite führt sie zu hoher Qualität in der Software-Erstellung.  

Wir wollen diese Aussage im Folgenden mittels der drei Herausforderungen zur Softwarequalität erläutern.

Das spezielle Qualitäts-Problem von Software

Zuerst wollen wir unser Ziel betrachten: Wir möchten (Shop-)Software übernehmen oder selbst entwickeln, bzw. weiterentwickeln und pflegen. Dabei stehen drei Herausforderungen im Zusammenhang mit der Softwarequalität im Vordergrund: 

Korrekte Modellierung der erforderlichen Anwendungsfälle 
Schnelle und vollständige Implementierung 
Erstellen und Pflegen vollständiger, automatisierter Tests 

Oder kurz und umgekehrt formuliert: Software hat Tendenzen, nicht das abzubilden was benötigt wird, zu spät und unvollständig und obendrein mit Mängeln bereitgestellt zu werden. 

Warum beobachten wir diese Mängel so stark bei Software? 

Oft fragt man sich, wieso diese Probleme so spezifisch bei Software auftreten, und nicht längst mit den üblichen, planerischen Methoden der Ingenieurswissenschaften geklärt werden konnten. Der Grund liegt darin, dass Software nicht – wie bei anderen Ingenieursprodukten – „proaktiv“ Produkte bereitstellt, die Standards und Verbrauchsverhalten der User definieren, sondern reaktiv auf komplexe Prozesse eingeht und sie korrekt modellieren muss: Eine Landung auf dem Mond, eine Drehung im All, die Berechnung von Luftströmungen, das Lotsen von Hochseeschiffen durch die stundenaktuellen Untiefen im Hamburger Hafen, die korrekte Verdichtung von Nutzerdaten, das buchhalterische Saldieren von Konten, die Zerlegung von Bestellungen in einzelne Fulfillments. Das alles sind komplexe Vorgänge, die sich als Modell korrekt an die Wirklichkeiten von vielen Umsystemen ankoppeln müssen. 

Lösungsstrategien für das Design komplexer Systeme 

Für das Lösen dieser Qualitäts-Herausforderungen gibt es unterschiedliche Strategien in unterschiedlichen Handlungsfeldern. In der Domäne „Projektmanagement“ gibt es beispielsweise die Methodik der Agilität bzw. der agilen Software- Entwicklung. Sie zielt darauf ab, in Projekt-Organisationen dafür zu sorgen, dass möglichst viel menschliche Kommunikation verschiedenster Wissensträger in kleinen, produktiven, leicht korrigierbaren Schritten erfolgt. Im Handlungsfeld „Design“ gibt es Methodiken, um Software effektiv, robust, skalierbar, weiterentwickelbar und wartbar zu machen. Eine Methode hierfür besteht in DDD, Domain Driven Design. Diese wollen wir im Folgenden genauer erläutern. 

Domain Driven Design – DDD 

Wir wollen nun zeigen, inwieweit DDD auf die drei oben genannten Herausforderungen bzw. Probleme Einfluss hat

Zuvor haben wir noch eine Vorbemerkung: Da DDD ein sehr komplexes Thema ist, versuchen wir hier möglichst einfache Strukturen und Begriffe zu verwenden. Sie müssen jedoch verstehen, dass sich DDD mit seinen Fundamenten und den daraus folgenden Konzepten in einer philosophischen, logischen Sphäre bewegt. Es hat dadurch (wie alles, aber hier unverkennbar) Unschärfe, die aber nicht nur nicht kritisch, sondern sogar produktiv sein kann.

Strategisches DDD 

Zuerst wollen wir zeigen, inwieweit das strategische Design von DDD die Anwendungen begünstigt: Im strategischen Design geht es zuvorderst darum, in sich abgeschlossene und vollständige Modelle zu finden, – die sog. Bounded Contexts im DDD-Jargon. Hierzu sammelt und sortiert man so lange die Domänen des Problem Space (also des Business) zusammen mit Fachexpert:innen und Technischen Expert:innen, bis man die Bereiche hat, in welchen alle klar vom selben reden – also ihre ‘ubiquitäre’ Model Language gefunden haben. 

Der Bounded Context ist das Modell

Für eine einzelne Domäne (bspw. Order Management, Catalogue Management) sieht ein reales Zielbild folgendermaßen aus: 

Es wird immer begriffliche, sprachliche Bereiche geben, in welchen sich fachliche und technische Expert:innen ihrem eigenen Jargon bedienen und sich dann untereinander nicht verstehen. Aber in ihrem Modell sprechen alle die gleiche Sprache und definieren und testen dessen Vollständigkeit und Abgeschlossenheit! 

Randnotiz: Einem Modell muss im Solution Space exakt ein Software-Team zugeordnet werden. Nicht mehrere! Dadurch wird die Abgeschlossenheit des Modells und dessen Verständlichkeit stark gefördert.  

Context Mapping – Redundanz in Modellen verschiedener Domänen

Eine entscheidende Eigenschaft von DDD ist, dass sie nicht alles in einem geschlossenen Modell entwirft. Das waren die entscheidenden Erkenntnisse von Eric Evans, dem Erfinder von DDD, dass es in (großen, einheitlichen) Modellen sprachliche, gedankliche und also letztendlich geschäftliche Spannungen gibt, wenn sie unter verschiedenen Kontexten gesehen werden. Beispielsweise müssen Policen andere Geschäftsregeln und Daten kennen, je nachdem, ob sie im Kontext des Risikomanagements oder der Schadensregulierung gesehen werden. Es ist daher viel effizienter für die Modellierung und Implementierung, die Modelle nach Kontext zu trennen und dasselbe Objekt mehrfach in den Modellen zu haben: 

An diesem Bild sieht man bereits sehr schön, wie DDD zu Microservices passt! 

Zusammenfassung und Ausblick

In diesem Beitrag haben wir gesehen, wie durch das strategische Design von DDD das vollständige Auffinden, Verteilen, Abgrenzen in Modellen erleichtert und schließlich deren Zuordnung zu verschiedenen Anwendungsfällen begünstigt. 

Damit ist DDD ein Instrument, um unser erstes Qualitätskriterium zu sichern: Die korrekte Modellierung der erforderlichen Anwendungsfälle.

Auch auf die Geschwindigkeit und Vollständigkeit der Implementierung zahlt strategisches Design ein, indem durch die Abgrenzung verschiedener Modelle die Autarkie von Entwicklungs-Teams gefördert wird und durch Kontextmapping die Abdeckung des kompletten Problem Space überprüft wird. 

Im nächsten Beitrag geht es um Taktisches Design, in welchem dann auch die Zuverlässigkeit des entwickelten Codes durch DDD-Methoden und deren Auswirkung auf die Software-Architektur im Vordergrund stehen.