Domain-Driven Design
Domain-Driven Design richtet Softwaremodelle an Fachwissen und gemeinsamer Sprache aus. Strategische Grenzen und taktische Modelle halten Bedeutungen und Regeln explizit.
- KerndomäneDer Teil, der den Shop unterscheidet.
- Gemeinsames ModellFachleute und Entwicklung teilen Begriffe und Regeln.
- Aufwand nach WertJe weniger Unterschied, desto schlichter.
Einordnung
Warum das wichtig ist
Fachleute und Entwicklung verstehen dieselbe Sache oft verschieden. Eric Evans beschreibt in „Domain-Driven Design“ (2003), den Kern der Domäne zuerst gemeinsam zu modellieren. Bounded Context, Aggregate und weitere Mittel vertiefen eigene Bausteine.
Dieser Baustein gibt Orientierung über Domain-Driven Design. Für einzelne Modellgrenzen siehe Bounded Context und für Konsistenzgrenzen siehe Aggregate.
Auf einen Blick · Gemeinsame Sprache formt das Modell
Wo investiert der Shop Modellierungsaufwand?
Im Shop sind nicht alle Module gleich wichtig. Die Bestellregeln unterscheiden ihn, die Zahlung kauft er beim Zahlungsanbieter ein. Danach richtet das Team seinen Modellierungsaufwand.
So liest du das Bild
- Kerndomäne Band „Kern“: Bestellung mit Bestell- und Stornoregeln.
- Gemeinsames Modell Beim Kern lautet der Umgang: gemeinsam mit Fachleuten modellieren.
- Aufwand nach Wert Die Bänder von Kern bis Generisch senken den Modellierungsaufwand.
KernCore Domain
Hier entsteht der fachliche Unterschied des Shops.
tief modellieren, gemeinsam mit Fachleuten
UnterstützendSupporting Subdomain
Nötig für den Betrieb, aber kein Alleinstellungsmerkmal.
schlicht und solide selbst umsetzen
GenerischGeneric Subdomain
Bei vielen Shops gleich, kaum eigene Besonderheit.
einkaufen oder Standardlösung nutzen
BestellungKern · tief modellieren, gemeinsam mit Fachleuten
Bestell- und Stornoregeln prägen den Ablauf des Shops und tragen das höchste fachliche Risiko.
Einordnung illustrativ
Die DDD-Mittel und wo sie vertieft werden
| Frage | DDD-Mittel | Ergebnis im Shop |
|---|---|---|
| 1. Welche Begriffe gelten? | Ubiquitous Language | Bestellung, Reservierung, Autorisierung |
| 2. Wo gilt ein Modell? | Bounded Context | Bestellung getrennt von Rechnung |
| 3. Wie arbeiten Modelle zusammen? | Context Map | Bestellung liefert Rechnungsdaten |
| 4. Welche Regeln bleiben konsistent? | Aggregate | Bestellung schützt Positions- und Statusregeln |
Nutzen & Grenzen
Hilft, wenn
- Fachliche Regeln und Ausnahmen prägen den Wert oder das Risiko eines Produkts.
- Wiederkehrende Missverständnisse zwischen Fachseite und Entwicklung führen zu falschen Zuständen oder Abläufen.
Grenzen
- DDD braucht regelmäßigen Zugang zu Fachleuten. Ohne ihn bleiben oft nur Musternamen („DDD lite“: taktische Muster wie Aggregate ohne strategischen Schnitt) und das gemeinsame Verständnis fehlt.
- DDD ist kein Architekturstil und verlangt keine Microservices. Der Shop bleibt ein modularer Monolith mit fachlich geschnittenen Modulen.
In der Praxis
- Fachlichen Kern eingrenzen. Bestimme, welche Regeln den größten Wert oder das höchste Fehlerrisiko tragen. Das Ergebnis legt fest, wo gemeinsame Modellierungsarbeit sinnvoll ist.
- Begriffe und Regeln an Fällen erkunden. Bitte Fachexperten, typische Abläufe, Grenzfälle und Entscheidungskriterien zu erläutern. Verankere die Begriffe mit Ubiquitous Language im Modell.
- Modell in Umsetzung und Feedback führen. Nutze geklärte Regeln in Code, Tests und Reviews und aktualisiere sie bei neuen Erkenntnissen. Halte unterschiedliche Modelle über Bounded Context getrennt.
Ausführliche Erklärung lesen
Fachexperten und Entwickler erkunden gemeinsam Begriffe, Entscheidungen und Ausnahmen der Domäne. Daraus entsteht ein Modell, das sich in Gespräch, Code und Tests wiederfindet. Strategische Modellierung ordnet fachliche Bereiche; taktische Muster gestalten Verhalten und Zustände innerhalb eines Bereichs. Bounded Context definiert den Geltungsbereich eines Modells, Ubiquitous Language verbindet es mit dem gemeinsamen Vokabular.
Der Aufwand konzentriert sich auf fachlich entscheidende Bereiche, in denen Regeln und Änderungen hohen Wert oder hohe Risiken tragen. Das Modell bleibt veränderbar, wenn neue Erkenntnisse hinzukommen. DDD ist kein Pflichtgerüst für jede Anwendung und ersetzt weder Nutzerwissen noch klare technische Grenzen.
Nicht jeder Teil der Fachdomäne verdient gleich viel Modellierungsaufwand: DDD unterscheidet Core, Supporting und Generic Subdomain. Im Shop ist Zahlung generisch und wird beim Zahlungsanbieter eingekauft. Die fachlichen Bestellregeln sind der Kern, in den das Team investiert; Katalog, Warenkorb, Lager und Versand setzt es als unterstützende Subdomänen schlicht und solide um.
Selbst prüfen
Teste dich in drei Stufen
AblesenIm Bild nachsehen
Welche Subdomäne kauft der Shop ein?
Lösung mit Begründung ansehen
Die Zahlung, eine generische Subdomäne. Der Zahlungsanbieter ist eingekauft, der Shop übersetzt seine Codes über eine Anti-Corruption Layer.
AnwendenAuf eine neue Lage übertragen
Der Shop führt Rabattregeln als Unterscheidungsmerkmal gegenüber anderen Shops ein. Wohin gehören sie?
Lösung mit Begründung ansehen
In den Kern. Regeln, die den Shop unterscheiden, verdienen tiefe Modellierung gemeinsam mit Fachleuten, etwa nahe an der Bestellung.
BewertenEine Alternative abwägen
Das Team will den Katalog mit Aggregaten und Value Objects aufwendig modellieren. Wie bewertest du das?
Lösung mit Begründung ansehen
Der Katalog ist unterstützend. Aufwendige Modellierung bindet Zeit, die dem Kern fehlt. Sinnvoll wäre eine schlichte, solide Umsetzung. Wächst der Katalog zum Unterscheidungsmerkmal, lohnt sich mehr Tiefe.
Vertiefen
Diese optionalen Vertiefungen ergänzen das Lernziel dieser Seite.
Event Storming
Event Storming ist ein gemeinsames Erkundungsformat: Fachleute und Entwicklung ordnen fachliche Ereignisse in Vergangenheitsform zeitlich, markieren offene Fragen und untersuchen unterschiedliche Deutungen. Im Shop könnte die Folge „Bestellung aufgegeben“, „Zahlung autorisiert“, „Bestand reserviert“ lauten. Das Ergebnis liefert Beobachtungen und Modellhypothesen; technische Grenzen und Kommunikationsformen werden danach gesondert entschieden.
Zum AusprobierenErkunde mit Fachleuten den Ablauf einer Shopbestellung. Ordne Ereignisse wie „Bestellung aufgegeben“ und „Zahlung autorisiert“ zeitlich, markiere offene Fragen und kläre unterschiedliche Bedeutungen, bevor du Modellgrenzen und technische Umsetzung festlegst.
Domain Service
Ein Domain Service modelliert eine fachliche Regel oder Berechnung, die keinem Entity oder Value Object natürlich gehört. Er bleibt in der Sprache der Domäne und erhält benötigte Informationen über explizite Eingaben oder Verträge. Ein Domain Service ist weder ein allgemeiner Anwendungsschritt noch automatisch ein Verteiler verteilter Transaktionen; Regeln über mehrere Konsistenzgrenzen brauchen weiterhin eine bewusste Prozesskoordination.
Zum AusprobierenPrüfe im Shop die Regel zur Versandfähigkeit: Wenn sie Gewicht, Liefergebiet und gewählte Versandart zusammen bewertet und keinem einzelnen Objekt gehört, modelliere sie als Domain Service mit fachlich benannten Eingaben. Halte Lagerreservierung und Bestellung als getrennte Vorgänge mit eigenem Ergebnis fest.
Weiterführende Bausteine
Quellen
- Martin Fowler · Domain-Driven Design (öffnet in neuem Tab)Erläutert fachliche Modelle und die strategische Aufteilung komplexer Domänen.
- Eric Evans · DDD Reference (öffnet in neuem Tab)Referenz des DDD-Autors zu strategischen und taktischen Mustern.
- Microsoft · DDD-oriented Microservice (öffnet in neuem Tab)Ordnet Fachmodell, Anwendungsschicht und Infrastruktur klaren Aufgaben zu.
- DDD Crew · Core Domain Charts (öffnet in neuem Tab)Vorlage, um Subdomänen nach Wert und Komplexität einzuordnen und den Kern zu bestimmen.
- EventStorming · Alberto Brandolini (öffnet in neuem Tab)Offizielle Einführung in die gemeinsame Erkundung fachlicher Abläufe und komplexer Domänen.
- Eric Evans · Domain-Driven Design Reference (öffnet in neuem Tab)Primärreferenz zu Services, Aggregaten, Repositories und Factories.