Domain-Driven Design

Kurz: Domain-Driven Design (DDD) richtet Software an der Fachlichkeit aus. Entwickler und Fachleute entwickeln eine gemeinsame Sprache, und der Code bildet die Fachbegriffe ab.

Genauer: Große Systeme werden in „Bounded Contexts“ geteilt, in denen jeder Begriff eine klare Bedeutung hat („Kunde“ im Vertrieb ist etwas anderes als in der Buchhaltung). Innerhalb eines Kontexts modelliert man mit Entitäten, Wertobjekten und Aggregaten.

Im Detail

• Ubiquitous Language: Einheitliche Fachsprache in Gesprächen und Code.
• Bounded Context: Grenze, in der ein Modell gilt. Oft passt er zu einem Microservice.
• Entität: Hat Identität (z. B. Kunde Nr. 42). Wertobjekt: Nur durch Werte bestimmt (z. B. Geldbetrag), unveränderlich.
• Aggregat: Gruppe von Objekten mit einer Wurzel, die Konsistenz sichert.
• Domain-Events: Wichtige Ereignisse der Fachlichkeit.
• Context Map: Beziehungen zwischen Kontexten (Anti-Corruption-Layer, Shared Kernel).
• Wann: Komplexe Fachlogik. Für einfaches CRUD ist es zu viel.

Siehe auch: Hexagonale Architektur, Event Sourcing und CQRS