Domain-Driven Design Grundlagen

Die Kernidee: Fokus auf die Fachdomäne

Domain-Driven Design (DDD) ist ein Ansatz zur Softwareentwicklung, der die Fachdomäne – also das spezifische Wissensgebiet und die Geschäftsprozesse, für die die Software entwickelt wird – in den Mittelpunkt stellt. Stell dir vor, du entwickelst eine Software für ein Logistikunternehmen. Bei DDD geht es nicht zuerst darum, die modernste Datenbanktechnologie auszuwählen, sondern darum, die komplexen Abläufe der Logistik – wie Routenplanung, Frachtverfolgung oder Lagerverwaltung – und deren Fachbegriffe exakt zu erfassen und als Herzstück der Software zu modellieren. Das Ziel ist, eine Software zu schaffen, die die Sprache und die Logik des Geschäfts präzise widerspiegelt und so echten Mehrwert für die Anwendenden liefert.

Ubiquitous Language: Eine gemeinsame Sprache für alle

Ein Kernkonzept von DDD ist die Ubiquitous Language (allgegenwärtige Sprache): eine gemeinsame, präzise Fachsprache, die von allen Projektbeteiligten – Fachexpert:innen, Entwickler:innen und Manager:innen – geteilt und konsequent verwendet wird. Wenn in einem Projekt für einen Online-Marktplatz alle Beteiligten von einem "Angebot", einem "Warenkorb" oder einer "Verkäuferbewertung" sprechen, meinen sie dank der Ubiquitous Language immer exakt dasselbe, mit denselben Eigenschaften und Regeln. Diese Sprache fließt in alle Diskussionen, Diagramme, Dokumentationen und, ganz wichtig, direkt in den Quellcode (z.B. in Klassennamen, Methodenbezeichnungen, Variablen). So werden Missverständnisse minimiert und das Softwaremodell bildet die Fachdomäne akkurat ab.

Warum DDD? Vorteile und Anwendungsbereiche

DDD entfaltet seine Stärken besonders bei der Entwicklung von Software für komplexe und sich entwickelnde Fachdomänen, bei denen ein tiefes Verständnis der Geschäftslogik erfolgskritisch ist. Die wichtigsten Vorteile sind:

• Verbesserte Kommunikation: Die Ubiquitous Language schafft ein gemeinsames Verständnis und reduziert Reibungsverluste zwischen Fachabteilungen und Entwicklungsteams.
• Höhere Softwarequalität: Da die Software die Fachdomäne genauer modelliert, erfüllt sie die tatsächlichen Geschäftsanforderungen besser und ist oft intuitiver für die Endanwendenden.
• Bessere Wartbarkeit und Erweiterbarkeit: Ein klares Domänenmodell, das die Geschäftslogik widerspiegelt, erleichtert zukünftige Anpassungen und Erweiterungen der Software.
• Stärkere Ausrichtung an Geschäftszielen: Der Fokus liegt auf der Lösung der Kernprobleme und der Unterstützung der strategischen Ziele des Unternehmens.

Voraussetzung für erfolgreiches DDD ist eine enge und kontinuierliche Zusammenarbeit zwischen Fachexpert:innen und dem Entwicklungsteam sowie die Bereitschaft, Zeit in das gemeinsame Erarbeiten und Verfeinern des Domänenmodells zu investieren.

Entitäten: Objekte mit eigener Identität

Entitäten sind zentrale Objekte im Domänenmodell, die eine eindeutige und überdauernde Identität besitzen. Diese Identität bleibt auch dann bestehen, wenn sich andere Eigenschaften oder der Zustand der Entität ändern. Stell dir eine Person vor, die Kund:in in einem Online-Shop ist. Diese Person wird durch eine eindeutige Kundennummer identifiziert. Selbst wenn die Person umzieht (Adresse ändert sich) oder heiratet (Name ändert sich), bleibt es dieselbe Person mit derselben Kundennummer. Die Identität ist das, was eine Entität ausmacht und sie von anderen Entitäten unterscheidet, auch wenn deren Attribute gleich wären.

Beispiele:

• Ein Benutzerkonto (identifiziert durch eine Benutzer-ID)
• Ein Flugticket (identifiziert durch eine Buchungsnummer)
• Ein Fahrzeug (identifiziert durch die Fahrgestellnummer)

Wertobjekte: Beschreibungen ohne eigene Identität

Wertobjekte (Value Objects) sind Objekte, die dazu dienen, beschreibende Aspekte einer Domäne zu modellieren. Im Gegensatz zu Entitäten haben sie keine eigene konzeptionelle Identität. Ihre Bedeutung ergibt sich ausschließlich aus der Kombination ihrer Attributwerte. Wenn zwei Wertobjekte dieselben Attributwerte haben, gelten sie als gleich und sind austauschbar. Wertobjekte sind oft unveränderlich (immutable): Wenn sich ein beschreibender Wert ändern soll, wird typischerweise ein neues Wertobjekt mit den geänderten Werten erstellt, anstatt das bestehende zu modifizieren.

Beispiele:

• Eine Anschrift (definiert durch Straße, Hausnummer, Postleitzahl, Ort – zwei identische Anschriften sind austauschbar)
• Ein Geldbetrag (definiert durch einen numerischen Wert und eine Währung – 20 EUR ist 20 EUR, egal "welche" 20 EUR)
• Ein Datumsbereich (definiert durch ein Start- und Enddatum).

Der Hauptunterschied: Entitäten haben eine eindeutige ID und einen Lebenszyklus, Wertobjekte werden durch ihre Werte definiert und sind oft unveränderlich.