Warum steht bei Domain-Driven Design die Fachdomäne im Mittelpunkt?
Die Kernphilosophie: Die Fachdomäne verstehen
Stell dir vor, du entwickelst eine Software für ein komplexes Logistikunternehmen. Wenn du sofort mit der Auswahl der Datenbank oder dem Schreiben von SQL-Queries beginnst, verfehlst du oft das eigentliche Ziel. Domain-Driven Design (DDD) dreht diesen Spieß um: Die Fachdomäne (das spezifische Geschäftsfeld) und ihre komplexe Logik stehen im absoluten Zentrum der Softwareentwicklung. Das Ziel von DDD ist es, dass die Software die realen Geschäftsprozesse – wie Routenplanung oder Frachtverfolgung – exakt abbildet. Dafür ist eine intensive, kontinuierliche Zusammenarbeit zwischen den Fachexpert:innen (die das Geschäft verstehen) und dem Entwicklungsteam (das die Technik beherrscht) zwingend erforderlich.
Ubiquitous Language: Die Brücke zwischen Fachbereich und Code
Das wichtigste Werkzeug für diese Zusammenarbeit ist die Ubiquitous Language (allgegenwärtige Sprache). Sie ist eine gemeinsam definierte, präzise Fachsprache, die von allen Projektbeteiligten konsequent genutzt wird. Wenn Fachexpert:innen von einer "Lieferung" sprechen, darf das Entwicklungsteam in der Datenbank nicht von einem "Paket" und im Code nicht von einem Shipment sprechen. Die Ubiquitous Language fließt direkt in den Quellcode ein: Klassen, Methoden und Variablen werden exakt so benannt, wie die Fachexpert:innen sprechen (z. B. class Lieferung). Das minimiert Missverständnisse drastisch und stellt sicher, dass das Domänenmodell die Realität fehlerfrei widerspiegelt.
Vorteile und der richtige Einsatzort
DDD ist kein Standardwerkzeug für jedes kleine Projekt. Es entfaltet seine Stärken primär bei komplexen Fachdomänen, in denen die Geschäftslogik der kritische Erfolgsfaktor ist (z. B. Bankenwesen, Versicherungen, Logistik).
Die konsequente Anwendung von DDD bietet entscheidende Vorteile:
- Verbesserte Kommunikation: Die gemeinsame Sprache bricht Silos zwischen Management, Fachabteilung und IT auf.
- Höhere Softwarequalität: Die Software löst die tatsächlichen Geschäftsprobleme, da sie exakt an der Domänenlogik ausgerichtet ist.
- Wartbarkeit: Wenn sich ein Geschäftsprozess ändert, lässt sich diese Änderung dank des klaren Domänenmodells leicht im Code lokalisieren und anpassen.
Wie unterscheiden sich Entitäten und Wertobjekte im DDD?
Entitäten: Objekte mit einer festen Identität
Du kennst Entitäten bereits aus der Entity-Relationship-Modellierung (ERM) als Informationsobjekte. Im taktischen Domain-Driven Design betrachten wir Entitäten (Entities) auf der Code-Ebene: Sie zeichnen sich durch eine eindeutige Identität aus, die über ihren gesamten Lebenszyklus hinweg bestehen bleibt, selbst wenn sich ihre Eigenschaften ändern.
Stell dir ein Kundenkonto vor. Wenn eine Kund:in heiratet und den Nachnamen ändert oder umzieht, ändern sich die Attribute. Dennoch bleibt es dieselbe Kund:in, identifizierbar durch die eindeutige Kundennummer (ID). Entitäten sind in der Regel veränderbar (mutable), da sich ihr Zustand im Laufe der Zeit anpassen kann, während ihre Identität konstant bleibt.
Wertobjekte: Reine Eigenschaften ohne Identität
Im Gegensatz dazu stehen Wertobjekte (Value Objects). Sie modellieren beschreibende Konzepte der Domäne und besitzen keine eigene Identität. Ihre Bedeutung ergibt sich ausschließlich aus der Kombination ihrer Werte.
Ein klassisches Beispiel ist ein Geldbetrag, bestehend aus einem Wert (z. B. 50) und einer Währung (z. B. EUR). Es ist völlig egal, welcher 50-Euro-Schein es ist – zwei Wertobjekte mit "50 EUR" sind absolut gleichwertig und austauschbar. Ein weiteres wichtiges Merkmal: Wertobjekte sind unveränderlich (immutable). Wenn sich eine Eigenschaft ändert (z. B. eine neue Hausnummer in einer Adresse), wird das bestehende Wertobjekt nicht verändert, sondern durch ein komplett neues Wertobjekt ersetzt.
Das Zusammenspiel in der Praxis
In einem sauberen Domänenmodell arbeiten Entitäten und Wertobjekte eng zusammen. Wertobjekte werden genutzt, um die Attribute von Entitäten zu beschreiben.
Ein Code-Beispiel zur Veranschaulichung:
// Die Entität (Entity) mit eindeutiger Identität (bestellnummer)
class Bestellung {
private String bestellnummer; // Identität
private Adresse lieferadresse; // Wertobjekt
public void aendereLieferadresse(Adresse neueAdresse) {
// Das alte Wertobjekt wird komplett durch ein neues ersetzt
this.lieferadresse = neueAdresse;
}
}
// Das Wertobjekt (Value Object) ohne eigene Identität
class Adresse {
// Attribute sind final, um Unveränderlichkeit zu garantieren
private final String strasse;
private final String stadt;
public Adresse(String strasse, String stadt) {
this.strasse = strasse;
this.stadt = stadt;
}
}Durch die Nutzung von unveränderlichen Wertobjekten für Eigenschaften wird der Code sicherer, leichter zu testen und das Domänenmodell bleibt übersichtlich.
Teste dein Wissen
Du startest ein neues Logistik-Projekt. Ein Kollege will sofort das Datenbankschema für die Fracht entwerfen. Was entgegnest du ihm laut Domain-Driven Design (DDD)?