Domain-Driven Design (DDD) ist ein Ansatz für die Modellierung komplexer Geschäftssoftware, bei dem die Fachdomäne ins Zentrum gestellt wird. Sprache, Code und Architektur orientieren sich an einer gemeinsamen, mit den Fachexperten erarbeiteten "Ubiquitous Language" innerhalb eines klar abgegrenzten Bounded Context.
DDD unterscheidet auf taktischer Ebene Bausteine wie Entities, Value Objects, Aggregates, Domain Events, Repositories und Domain Services. Strategisch werden große Systeme in Bounded Contexts geschnitten, deren Beziehungen über Context Maps mit Mustern wie Customer/Supplier, Conformist oder Anti-Corruption Layer beschrieben werden.
Klassische CRUD-Architekturen geraten an ihre Grenzen, wenn Geschäftsregeln vielfältig und veränderlich sind; DDD bringt diese Logik explizit ins Modell und vermeidet Anämische Datenmodelle, in denen Verhalten in Service-Klassen verstreut wird.
DDD wurde 2003 von Eric Evans in dem grundlegenden Buch "Domain-Driven Design: Tackling Complexity in the Heart of Software" beschrieben. Vaughn Vernon ergänzte es 2013 mit "Implementing Domain-Driven Design" um konkrete Implementierungsmuster, einschließlich des Zusammenspiels mit CQRS, Event Sourcing und Microservices.
Die strategischen Konzepte - insbesondere Bounded Context und Context Map - haben durch die Microservices-Welle ab 2014 stark an Bedeutung gewonnen, weil sie eine systematische Antwort auf die Frage liefern, wie Services geschnitten werden sollten. Heute zählt DDD zum Standardvokabular moderner Architektur.
Bei bluehands wird DDD konsequent angewendet und mit anderen Patterns wie HATEOAS und CQRS kombiniert um stark evolvierbare Produkte zu ermöglichen.