Was ist Domain-Driven Design (DDD)?

Domain-Driven Design (DDD) ist ein Ansatz zur Entwicklung komplexer Softwaresysteme, bei dem die fachliche Domäne im Mittelpunkt steht. Softwarestruktur und Fachsprache sollen die realen Geschäftsregeln und Prozesse möglichst präzise abbilden.

DDD ist weder ein einzelnes Entwurfsmuster noch eine fertige Softwarearchitektur. Es umfasst strategische und taktische Methoden, mit denen Fachbereiche und Entwicklungsteams ein gemeinsames Modell erarbeiten und weiterentwickeln.

Strategische Elemente von DDD

• Ubiquitous Language:
  Fachliche und technische Beteiligte verwenden eine gemeinsame, eindeutige Sprache. Begriffe aus dieser Sprache spiegeln sich auch im Modell und im Code wider.
• Bounded Context:
  Ein komplexes Fachgebiet wird in klar abgegrenzte Bereiche aufgeteilt. Innerhalb eines Bereichs besitzt ein Begriff eine eindeutige Bedeutung und ein eigenes Modell.
• Context Mapping:
  Die Beziehungen und Abhängigkeiten zwischen den abgegrenzten Bereichen werden sichtbar gemacht und bewusst gestaltet.

Taktische Bausteine von DDD

• Entities:
  Objekte mit einer dauerhaften Identität, deren Zustand sich im Laufe der Zeit verändern kann.
• Value Objects:
  Objekte, die durch ihre Werte beschrieben werden und in der Regel unveränderlich sind.
• Aggregates:
  Gruppen zusammengehöriger Objekte mit klaren Regeln und einer definierten Zugriffsstelle, der Aggregate Root.
• Domain Services und Domain Events:
  Sie bilden fachliches Verhalten beziehungsweise bedeutsame Ereignisse ab, die nicht sinnvoll einer einzelnen Entity zugeordnet werden können.
• Repositories:
  Sie kapseln den Zugriff auf persistierte Aggregate und halten technische Speicherlogik vom Domänenmodell fern.

Wann ist Domain-Driven Design sinnvoll?

DDD eignet sich besonders für Systeme mit umfangreichen Geschäftsregeln, mehreren Fachbereichen und Begriffen, deren Bedeutung vom Kontext abhängt. Der Ansatz kann helfen, Zuständigkeiten zu klären und komplexe Software langfristig weiterzuentwickeln.

Für kleine Anwendungen mit einfachen Datenoperationen kann der zusätzliche Modellierungsaufwand unverhältnismäßig sein. DDD sollte daher nicht automatisch auf jedes Projekt angewendet werden.

Ist DDD an Microservices gebunden?

Nein. Bounded Contexts können sinnvolle Grenzen für Microservices liefern, DDD lässt sich aber ebenso in einem modularen Monolithen einsetzen. Umgekehrt ist nicht jeder Microservice automatisch nach DDD gestaltet. Entscheidend ist die fachlich begründete Abgrenzung, nicht die Anzahl der deploybaren Dienste.