> Das Wichtigste in Kürze: Domain-driven Design (DDD) strukturiert Software anhand der Fachdomäne statt der Technik. Kernkonzepte: Bounded Contexts für klar abgegrenzte Fachbereiche, Entities und Value Objects für die Domänenmodellierung und eine Ubiquitous Language als gemeinsame Sprache zwischen Entwicklern und Fachexperten.

Software ist selten Selbstzweck, sondern wird als nützliches Werkzeug in konkreten, abgegrenzten Aufgabenbereichen eingesetzt. Dieser spezifizierte Anwendungs- oder Problembereich wird als Anwenderdomäne bezeichnet. Im Entwicklungsansatz des Domain-Driven Design (DDD) wird versucht, einen Anwendungs- oder Fachbereich und die darin anfallenden Prozesse so akkurat wie möglich abzubilden.

Grundprinzipien von Domain-Driven Design

Ubiquitous Language

Das zentrale Konzept von DDD: Entwickler und Fachexperten verwenden eine gemeinsame Sprache. Statt technischer Begriffe im Code werden die Fachbegriffe der Domäne verwendet. Wenn die Buchhaltung von „Rechnungen" und „Gutschriften" spricht, heißen die Klassen im Code Invoice und CreditNote – nicht Document oder Transaction. Diese gemeinsame Sprache reduziert Missverständnisse und sorgt dafür, dass der Code die Geschäftslogik direkt widerspiegelt.

Bounded Contexts

Große Systeme bestehen aus mehreren abgegrenzten Kontexten, in denen Begriffe unterschiedliche Bedeutungen haben können. Ein „Kunde" im Vertrieb ist nicht dasselbe Konzept wie ein „Kunde" im Support. DDD macht diese Grenzen explizit und definiert klare Schnittstellen zwischen den Kontexten. In einer Microservice-Architektur entspricht ein Bounded Context häufig einem eigenen Service.

Entities und Value Objects

Entities haben eine eindeutige Identität, die über ihre Lebensdauer bestehen bleibt (z. B. ein Kunde mit einer Kundennummer). Value Objects hingegen sind durch ihre Attribute definiert (z. B. eine Adresse oder ein Geldbetrag). Die Unterscheidung beeinflusst Design, Persistenz und Gleichheitsvergleiche.

Aggregates

Ein Aggregate ist ein Cluster von Entities und Value Objects, das als Einheit behandelt wird. Zugriffe von außen erfolgen nur über die Aggregate Root. Dies stellt die Konsistenz innerhalb des Aggregates sicher und vereinfacht die Parallelisierung.

Wann DDD sinnvoll ist

Domain-Driven Design entfaltet seinen Wert bei komplexer Geschäftslogik – nicht bei einfachen CRUD-Anwendungen. Wenn die Fachlogik komplex ist, sich häufig ändert und tiefes Domänenwissen erfordert, hilft DDD, diese Komplexität beherrschbar zu machen. Für einfache Datenmanagement-Anwendungen wäre DDD Over-Engineering.

DDD in der Praxis

Event Storming

Ein Workshop-Format, bei dem Entwickler und Fachexperten gemeinsam die Geschäftsprozesse als Abfolge von Domain Events modellieren. Das Ergebnis: ein gemeinsames Verständnis der Domäne und eine direkte Vorlage für die Software-Architektur.

CQRS und Event Sourcing

Häufig in Kombination mit DDD eingesetzt: CQRS (Command Query Responsibility Segregation) trennt Lese- und Schreiboperationen; Event Sourcing speichert den Zustand als Abfolge von Events. Beide Patterns eignen sich besonders für komplexe Domänen mit hohen Anforderungen an Nachvollziehbarkeit und Skalierbarkeit.---

Praktische Tipps zur Einführung von DDD

Die Einführung von Domain-Driven Design gelingt am besten schrittweise: Beginnen Sie mit einem klar abgegrenzten Bounded Context und einer gemeinsamen Sprache mit den Fachexperten. Vermeiden Sie zu große Modelle am Anfang. Refactorings und die schrittweise Ablösung alter Strukturen durch domänengetriebene Module reduzieren Risiken. Ein erfahrenes Team oder externer Support kann helfen, typische Fallstricke wie zu techniklastige Modelle oder unklare Kontextgrenzen zu vermeiden.

Domain-driven Design