Was ist Domain-driven Design? - Einführung

Vor vielen Jahren fügte ein talentierter Software-Designer die Bearbeitungsfunktion „Divide and Conquer“ („Teile und herrsche“) in ein beliebtes Layout-Programm für Zeitungen ein. Die Funktion war gut konzipiert, aber niemand nutzte sie. Das hatte folgenden Grund:

1. Die Bezeichnung „Divide and Conquer“ hatte in Bezug auf das Layout von Zeitungen keinerlei Bedeutung.
2. Niemand konnte erklären, was die Funktion tat oder weshalb man sie nutzen sollte.
3. Niemand hatte danach gefragt und keiner wollte sie.

Im Grunde wurde mehr Fokus darauf gelegt, was man mit dem Programm tun konnte, statt zu überlegen, warum man die Funktion damit benutzen sollte. 

Hier kommt Domain-driven Design (DDD) ins Spiel, ein Ansatz für die Software-Entwicklung, der sich darauf konzentriert, die Domäne, in dem die Software eingesetzt werden soll, vollständig zu verstehen. Wenn Sie die Domäne verstehen, bleibt das Risiko geringer, Funktionen hinzuzufügen, die Kunden nicht brauchen oder wünschen.

Was ist Domain-driven Design (DDD)?

Software soll unser Leben einfacher machen. Sie kann Prozesse optimieren und automatisieren oder Bereiche ansprechen, die für bestimmte Nutzer von Interesse sind. Diese Bereiche sind die Domänen, für die eine Software vorgesehen ist. Die Domäne von Digital-Audio-Workstation-(DAW-)Software ist beispielsweise die Industrie für Audioaufzeichnungen.  

Der Software-Entwickler Eric Evans erkannte die Notwendigkeit, die Software-Domäne zu verstehen. Mit seinem Buch „Domain-Driven Design: Tackling Complexity in the Heart of Software“ führte er das Konzept des DDD ein. Im Buch spricht Evans davon, dass das Herzstück von Software ihre Fähigkeit sei, domänenbezogene Probleme für ihre Nutzer zu lösen. Alle anderen Funktionen, und seien sie noch so wesentlich, unterstützten diesen grundlegenden Zweck.

Mit Blick auf unser obiges Beispiel, dem Zeitungslayout, bedeutet das, Sie müssen kein professioneller Layouter sein, um eine nützliche Layout-Software zu entwickeln. Sie müssen aber verstehen, wie Layouter ihre Arbeit machen, wenn Sie Software entwickeln möchten, welche die realen Prozesse und Verfahren eines Layouters abbildet. Funktionen, die jenseits dessen liegen, was sie brauchen, haben wenig bis keinen Nutzen.

Grundsätze von Domain-driven Design

Grundlegend geht es beim DDD um die Entwicklung von Software, die reale Systeme und Prozesse modelliert. Die Basis des DDD-Ansatzes bilden die folgenden Grundsätze:

• Fokus auf die Kernfachlichkeit: Bevor Sie mit dem Coden beginnen, sprechen Sie mit Leuten, die in der Domäne arbeiten. Sie können Ihnen dabei helfen, alle Prozesse, Verfahren und die Terminologie der Domäne zu definieren. Wenn Sie beispielsweise Software für die Bestandsverwaltung im Einzelhandel entwickeln, reden Sie mit jenen, die Lagerbestände verwalten, statt mit Mitarbeitenden aus der Personal- oder Finanzabteilung.
• Komplexität reduzieren durch Entwürfe, die auf Domänenmodelle basieren: Wenn Sie die Geschäftsdomäne verstehen, erstellen Sie ein Modell, das die reale Domäne widerspiegelt. Ihre Bestandsverwaltungssoftware sollte so etwa Funktionen enthalten, die für Bestandsverwalter wichtig sind. Dazu gehören die Analyse von Bestandstrends, die automatische Aufstockung von Beständen, das Scannen von Barcodes und so weiter. Das Modell ist ein Diagramm, ein Schaubild oder ein kurzer schriftlicher Text. Darin organisieren und abstrahieren Sie das Fachwissen des Domänenexperten.
• Eine gemeinsame Sprache sprechen: In seinem Buch spricht Evans über die Bedeutung von universeller Sprache. Alle am Projekt Beteiligten sollten die gleiche Sprache verwenden, um über die Domäne zu sprechen. Hören Sie sich die Wörter und Ausdrücke an, welche die Fachexperten verwenden. Übernehmen Sie dieselben Begriffe in ihr Anforderungsdokument, ins Modell und in den Code selbst.

Die wichtigsten Begriffe im Domain-driven Design

Die folgenden gängigen Begriffe sind nützlich, wenn Sie sich mit DDD beschäftigen:

• Fachlogik: Wird auch als Geschäftslogik bezeichnet. Das ist der Zweck des Modells und Software-Entwurfs. Der Entwurf basiert auf der Logik von realen Geschäftsregeln. Diese werden in Programmiercode übersetzt.
• Entwurfsmuster: Wenn bereits Code vorhanden ist, der ein ähnliches Problem löst, an dem Sie arbeiten, dann passen Sie ihn für Ihre Zwecke an. Versuchen Sie nicht jedes Mal, das Rad neu zu erfinden.   
• Kontext: Die Einstellung oder Umgebung, welche die Bedeutung eines Wortes, einer Aktion oder Funktion innerhalb der Softwaredomäne bestimmt. In einem bestimmten Kontext kann es beispielsweise sinnvoll sein, die Schaltfläche „Anwenden“ statt die Schaltfläche „Speichern“ zu verwenden.
• Kontextgrenzen: Große Projekte haben in der Regel viele Modelle, die integriert werden müssen. Eine Kontextgrenze definiert den logischen Rahmen, in dem sich ein Modell entwickeln kann. Das hilft anderen Teams, zu verstehen, was sie tun müssen, damit ihre Modelle gültig sind, wenn sie zu anderen hinzugefügt werden.
• Kontextübersicht: Ein Dokument, eine Grafik oder ein Diagramm, das die Beziehungen zwischen mehreren Kontextgrenzen beschreibt. Die Übersicht zeigt die Sprache jedes Kontexts, die unabhängige Implementierung und die Schnittstelle, welche für die Kommunikation mit anderen Kontextgrenzen verwendet wird.
• Entitäten: Eine Entität ist ein Domänenobjekt, das durch ihre eindeutige Kennung und nicht durch Attribute definiert wird. Beispiel: Eine Person kauft ein Ticket, um ins Kino zu gehen. Die Person ist eine Entität, da die eindeutige Kennung definiert, wer diese Person ist, unabhängig von Veränderungen der Haarfarbe, des Gewichts oder der Größe usw. 
• Wertobjekte: Ein unveränderliches Objekt, das Attribute, aber keine eindeutige Identität hat. Beispiel: Sie kaufen eine Kinokarte ohne zugewiesenen Sitzplatz. Alle Sitze im Kino sind gleich. Die Sitze sind festgeschraubt und können nicht verschoben werden, aber mit Ihrem Ticket können Sie jeden freien Sitzplatz auswählen. In diesem Zusammenhang ist der Sitz ein Wertobjekt.

Vorteile von Domain-driven Design

Am offensichtlichsten ist wohl der Vorteil, dass im DDD alle Beteiligten die gleiche Sprache verwenden. Wenn Entwicklungsteams dieselbe Sprache verwenden wie Fachexperten, führt das zu einem Software-Design, das für den Endnutzer Sinn ergibt. Weil die Terminologie in der Anwendung den Aktivitäten der Wirklichkeit entspricht, gibt es weniger Verwirrung und Nutzer verstehen schneller, wie das Produkt zu verwenden ist.

Weitere Vorteile:

• Geschäft und Entwicklung sind aufeinander abgestimmt: Weil beide dieselbe Sprache verwenden, können die Entwickler besser mit dem Geschäftsteam kommunizieren und verstehen es auch besser. Durch diese Abstimmung gibt es weniger Verwirrung und Missverständnisse zwischen Entwicklungsteam und Fachexperten.
• Schutz von Fachwissen: Wertvolles Wissen geht nicht verloren, wenn Teams sich anderen Projekten zuwenden oder wenn neue Mitarbeiter mit der Betreuung bestehender Projekte betraut werden.
• Mehr Flexibilität: Die Kontextdefinitionen und -grenzen erleichtern den Umgang mit Anforderungsänderungen, weil alle Beteiligten das gleiche Verständnis von der Geschäftsdomäne haben.
• Einfache Nachverfolgung: Bessere Kommunikation und eine gemeinsame Terminologie erleichtern die Nachverfolgung der Umsetzung von Anforderungen.
• Bessere Ausgewogenheit von Anwendungen: Manchmal liegt der Schwerpunkt zu sehr auf der UX/UI der Software. Diese sind zwar wichtig, können aber zu Problemen führen, wenn einige Anforderungen der Domäne vernachlässigt werden. Es spielt keine Rolle, wie schick das Programm aussieht, wenn es nicht das tut, was die Nutzer wollen. Konzentrieren Sie sich darauf, was die Domäne braucht und was die Fachexperten empfehlen, damit die Software ausgewogen Kundenbedürfnisse und -erwartungen erfüllt.
• Besserer Code: Mit dem DDD-Ansatz erhalten Sie letztlich saubereren, zuverlässigeren Code. So können Sie auch wiederholbare Best Practices und Design-Muster festlegen, damit künftige Projekte reibungsloser und effizienter laufen.

Nachteile von Domain-driven Design

Domain-driven Design bietet viele Vorteile, doch es ist nicht unbedingt für jeden in jeder Situation geeignet. Hier sind ein paar Nachteile:

• Umfassende Fachkenntnisse erforderlich: Sie benötigen mindestens einen Fachexperten im Team. Dieser Experte muss alles über die Domäne wissen, in der die Software zum Einsatz kommen soll. Ohne diese Art von Wissen könnten Sie sonst mit Funktionen enden, die nicht in den Kontext der Domäne passen.
• Funktioniert nur, wenn die Domäne komplex ist: Wenn die Domäne relativ einfach ist, könnte DDD ein zeitraubendes „Zuviel“ sein. So könnten bei der Entwicklung von Software für eine Domäne für Bewerbungen eventuell nur ein paar einfache Formulare für die Eingabe personenbezogener Daten, frühere Arbeitserfahrung, Referenzen, Notfallkontakte usw. benötigt werden. Wenn Sie keinen dedizierten Fachexperten brauchen, dann brauchen Sie wahrscheinlich kein DDD.
• Bei hochtechnischen Projekten unter Umständen nur bedingt geeignet: Der Fokus auf komplexe Geschäftsbereiche und -logiken funktioniert gut, weil Sie eine gemeinsame Sprache zwischen Entwicklern und Fachexperten entwickeln können. Wenn das Projekt allerdings technisch komplex ist, ist es schwierig, eine gemeinsame Sprache zu entwickeln, die Personen auf der Geschäftsseite verstehen.
• Großer Zeitaufwand möglich: Wenn Ihre Entwickler nicht bereits Fachexperten sind, müssen sie viel Zeit mit dem Geschäftsteam verbringen, um ein tiefes Verständnis für die Domäne zu entwickeln. Allerdings kann sich diese Zeit auch als Vorteil erweisen, wenn das gesamte Domänenwissen erfasst wird. 

Wenn Ihr Unternehmen Software gestalten möchte, die sich gut in die vorgesehene Geschäftsdomäne einfügt, dann überlegen Sie sich, DDD einzusetzen. Doch auch wenn DDD nicht das Richtige für Sie ist, lohnt es sich, den Ansatz zu erlernen, denn er kann Ihnen dabei helfen, die Kommunikation zwischen Ihren Entwicklungsteams und Fachexperten zu verbessern. Und eine bessere Kommunikation führt zu besseren Problemlösungen sowie nützlicherer Software.