Domain-Driven Design (DDD) ist ein Ansatz der Softwareentwicklung, der die fachliche Domäne in den Mittelpunkt stellt. Statt technischer Details bestimmen die Begriffe, Regeln und Abläufe des Fachbereichs (etwa Bestellwesen, Versicherung oder Logistik) die Architektur der Software. Geprägt wurde der Begriff von Eric Evans in seinem Buch „Domain-Driven Design: Tackling Complexity in the Heart of Software“ (2003), im Fachjargon auch „Blue Book“ genannt. Die praktische Umsetzung beschrieb Vaughn Vernon 2013 in „Implementing Domain-Driven Design“.
Strategisches und taktisches Design
DDD unterscheidet zwei Ebenen: Das strategische Design betrachtet das große Ganze — es zerlegt die Domäne in Subdomänen (Kerndomäne, unterstützend, generisch) und grenzt die Bereiche über Bounded Contexts voneinander ab. Das taktische Design liefert die Bausteine für den Code: Entities (Objekte mit Identität), Value Objects (unveränderliche Werte), Aggregates (Konsistenzgrenzen mit einer Aggregate Root), Repositories und Domain Services.
Warum DDD?
Komplexe Fachlogik scheitert oft an Missverständnissen zwischen Fachexperten und Entwicklern. DDD begegnet dem mit einer gemeinsamen Ubiquitous Language: Fachbegriffe werden überall einheitlich verwendet — im Gespräch, in der Dokumentation und im Code. Das Modell wird gemeinsam mit den Fachexperten entwickelt und bleibt dadurch nah an der Realität.
DDD eignet sich besonders für Microservices: Jeder Dienst bekommt seinen eigenen Bounded Context. Die Abgrenzung der Kontexte hilft, die Services unabhängig zu halten. Auch ereignisgetriebene Architekturen wie Event Sourcing und CQRS bauen häufig auf DDD auf.
Verwandte Grundlagen: Bounded Context, Ubiquitous Language, Objektorientierung, Event-Driven Architecture, Monolith.