Domain-driven Design

> 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

Kurz: Domain-Driven Design entfaltet seinen Wert bei komplexer Geschäftslogik – nicht bei einfachen CRUD-Anwendungen.

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.---

Verwandte Artikel

• 18 Open‑Source‑Shopsysteme im Überblick – Stärken,...
• Was ein App-Programmierer können muss
• Gamification kurz erläutert

Praktische Tipps zur Einführung von DDD

Kurz: 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.

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.## DDD für komplexe Domänen – pragmatisch eingesetzt

Strategic Design (Bounded Contexts) verhindert, dass ein einziges monolithisches Modell alle Fachbereiche überfrachtet. Tactical Patterns wie Entities, Value Objects und Repositories helfen, wenn die Domäne wirklich komplex ist – nicht bei jeder CRUD-App.

Schnittstellen zwischen Kontexten

Kurz: Anti-Corruption Layer und klare Übersetzungsschichten reduzieren Kopplung.

Anti-Corruption Layer und klare Übersetzungsschichten reduzieren Kopplung. Für API-Design passen Artikel zu APIs in modernen Architekturen.

Workshops und iteratives Modell

Kurz: DDD funktioniert am besten in iterativen Workshops mit Fachexpert:innen: gemeinsame Begriffe schärfen, Grenzen ziehen, Beispiele durchspielen.

DDD funktioniert am besten in iterativen Workshops mit Fachexpert:innen: gemeinsame Begriffe schärfen, Grenzen ziehen, Beispiele durchspielen. Modelle sind nie endgültig – neue Geschäftsregeln erzwingen Anpassungen. Die Softwarearchitektur sollte diese Evolution unterstützen, statt durch starre Schemata zu blockieren. Groenewold IT moderiert solche Sessions und übersetzt Ergebnisse in belastbare Schnittstellen – Individuelle Softwareentwicklung.

Fazit

Kurz: DDD ist Werkzeugkasten, nicht Dogma.

DDD ist Werkzeugkasten, nicht Dogma. Groenewold IT strukturiert Software nach fachlicher Tiefe – Individuelle Softwareentwicklung.

Vertiefung: Bounded Contexts in Middleware- und App-Projekten

Kurz: Auch Mobile-Apps profitieren von klarer Sprache: Begriffe aus dem Fachbereich sollten in Modulnamen, Events und APIs konsistent sein.

Auch Mobile-Apps profitieren von klarer Sprache: Begriffe aus dem Fachbereich sollten in Modulnamen, Events und APIs konsistent sein. Übersetzungsschichten zwischen Altsystemen und neuen Kontexten verhindern „Modell-Klecks“. Event-getriebene Integration erleichtert lose Kopplung, erfordert aber Versionierung und Idempotenz. Groenewold IT modelliert komplexe Domänen – Individuelle Softwareentwicklung, API-Rolle.

Lesetipps

• APIs
• Refactoring
• Schulden vermeiden

Langform: Ubiquitous Language, Events und Schnittstellenverträge

Kurz: Ubiquitous Language bedeutet, dass Produkt, Fachbereich und Engineering dieselben Begriffe nutzen – von User Story bis Datenbankfeld.

Ubiquitous Language bedeutet, dass Produkt, Fachbereich und Engineering dieselben Begriffe nutzen – von User Story bis Datenbankfeld. Events zwischen Kontexten sollten versioniert und abwärtskompatibel evolieren, damit Mobile Clients nicht bei jedem Backend-Deploy brechen. Anti-Corruption Layer kapseln Fremdmodelle und verhindern, dass Legacy-Begriffe Ihre neue Domäne vergiften. Groenewold IT begleitet Modellierungs-Workshops – Individuelle Softwareentwicklung.

Ergänzung: Modellierung in Workshops und iteratives Schärfen

Kurz: DDD lebt von gemeinsamen Workshops mit Fachdomainen: Begriffe schärfen, Grenzen ziehen, Beispiele durchspielen.

DDD lebt von gemeinsamen Workshops mit Fachdomainen: Begriffe schärfen, Grenzen ziehen, Beispiele durchspielen. Modelle sind nie „fertig“ – sie werden mit jedem neuen Use Case überprüft. Technische Implementierung sollte diese Evolution unterstützen, statt sie durch starre Schemata zu blockieren.

Ergänzung: Von der Sprache zum lauffähigen System

Kurz: Ein gemeinsames Modell zwischen Fachbereich und IT reduziert Missverständnisse in Schätzungen, Tests und Supportfällen.

Ein gemeinsames Modell zwischen Fachbereich und IT reduziert Missverständnisse in Schätzungen, Tests und Supportfällen. Groenewold IT begleitet Modellierung und Umsetzung – Individuelle Softwareentwicklung.

Abschlussblock: Kontextgrenzen und Evolution

Kurz: Bounded Contexts leben – neue Geschäftsregeln verschieben Grenzen.

Bounded Contexts leben – neue Geschäftsregeln verschieben Grenzen. Planen Sie deshalb Übergänge zwischen Kontexten explizit, statt stiller Kopplung. Groenewold IT moderiert solche Übergänge – Schnittstellen-Entwicklung.

Nachschlag: Ubiquitous Language in Reviews

Kurz: Nutzen Sie Fachbegriffe aus dem Domänenmodell in Tickets, Pull Requests und Tests – so bleibt die Sprache zwischen Fachbereich und Entwicklung synchron.

Nutzen Sie Fachbegriffe aus dem Domänenmodell in Tickets, Pull Requests und Tests – so bleibt die Sprache zwischen Fachbereich und Entwicklung synchron. Widersprüche im Wording sind oft erste Hinweise auf falsche Annahmen im Modell. Regelmäßige Sessions mit Fachexpert:innen halten das Glossar aktuell. Groenewold IT begleitet solche Formate – Individuelle Softwareentwicklung.

Ergänzung: Aggregates und Invarianten testen

Kurz: Schreiben Sie Tests, die Geschäftsregeln explizit benennen – nicht nur happy paths.

Schreiben Sie Tests, die Geschäftsregeln explizit benennen – nicht nur happy paths. Wenn eine Invariante verletzt wird, soll der Fehler im Domänencode sichtbar werden, nicht erst in der UI. Groenewold IT unterstützt bei testgetriebener Modellierung – Individuelle Softwareentwicklung.

Mini-Block: Schnittstellen zwischen Kontexten versionieren

Kurz: Wenn zwei Bounded Contexts über Events oder REST sprechen, sind Breaking Changes teuer – etablieren Sie Versionierung, Deprecation-Pfade und Consumer-getriebene Verträge früh.

Wenn zwei Bounded Contexts über Events oder REST sprechen, sind Breaking Changes teuer – etablieren Sie Versionierung, Deprecation-Pfade und Consumer-getriebene Verträge früh. Groenewold IT plant solche Übergänge – Schnittstellen-Entwicklung.

Entities vs. Value Objects im Detail

Kurz: Entities haben eine identitätsstiftende Eigenschaft (oft eine ID), die über die Zeit hinweg bestehen bleibt, auch wenn sich andere Attribute ändern – z.

Entities haben eine identitätsstiftende Eigenschaft (oft eine ID), die über die Zeit hinweg bestehen bleibt, auch wenn sich andere Attribute ändern – z. B. ein Kunde, dessen Adresse wechselt, aber dieselbe Kundennummer behält.

Value Objects haben keine eigene Identität; sie werden durch ihre Werte definiert und sollten unveränderlich (immutable) modelliert werden – z. B. Geldbetrag mit Währung oder ein Adressblock. Wenn Sie jedes Adressfeld einzeln auf einer Entity mutieren, verwischen Grenzen; kapseln Sie stattdessen Werte in Objekte mit Validierung beim Erzeugen.

So bleiben Invarianten („Betrag nie negativ“) zentral und testbar.

Repositories: Abgrenzung, Tests und Anti-Patterns

Kurz: Repositories kapseln den Zugriff auf persistente Daten und sprechen die Domänensprache (z.

Repositories kapseln den Zugriff auf persistente Daten und sprechen die Domänensprache (z. B. findActiveContractFor(customerId)) statt SQL-Fragmente in Services zu streuen. Sie gehören zur infrastrukturellen Schicht oder zu einem klar definierten Port, nicht in UI-Code. Gute Tests nutzen In-Memory- oder Fake-Implementierungen, um Domänenlogik ohne Datenbank zu prüfen.

Anti-Patterns: „God-Repository“ für alle Tabellen, generische save(object: any)-APIs ohne Domänenbedeutung, oder Repositories, die Geschäftsregeln verstecken – das erschwert Lesbarkeit und Wartung.

Domain Events: Konsistenz, Integration und Eventualität

Kurz: Domain Events dokumentieren, dass in der Domäne etwas Wesentliches passiert ist (z.

Domain Events dokumentieren, dass in der Domäne etwas Wesentliches passiert ist (z. B. „Auftrag freigegeben“). Sie helfen, Seiteneffekte (Benachrichtigung, Statistik, externe Schnittstelle) von der Kernlogik zu trennen – oft über einen kontrollierten Dispatcher im selben Transaktionskontext oder über eine spätere Outbox. Wichtig ist die Abgrenzung zu technischen Integrationsevents: Domänenereignisse sollten geschäftlich lesbar sein. Bei verteilten Systemen gelten Eventual Consistency und Idempotenz auf der Konsumentenseite; sonst führen doppelte Zustellungen zu doppelten Buchungen. Vertiefung auch im Glossar: Domain-Driven Design und unsere Softwareentwicklung.

Bounded Contexts und strategisches Design

Kurz: Bounded Contexts begrenzen, wo ein Begriff eine eindeutige Bedeutung hat – „Kunde“ im CRM ist nicht dasselbe Modell wie „Kunde“ in der Faktura, auch wenn der Name identisch klingt.

Bounded Contexts begrenzen, wo ein Begriff eine eindeutige Bedeutung hat – „Kunde“ im CRM ist nicht dasselbe Modell wie „Kunde“ in der Faktura, auch wenn der Name identisch klingt. Explizite Context Maps (Partnership, Shared Kernel, Anti-Corruption Layer) verhindern, dass Teams stillschweigend dieselben Tabellen für widersprüchliche Regeln nutzen.

Ein Anti-Corruption Layer übersetzt fremde Modelle in die eigene Sprache und schützt die Kern-Domäne vor API- oder ERP-Details.

Ubiquitous Language und Modellierung im Team

Kurz: Die Ubiquitous Language lebt in Workshops, User Stories und Code: Begriffe aus Fachabteilung und Entwicklung sollen zusammenfallen.

Die Ubiquitous Language lebt in Workshops, User Stories und Code: Begriffe aus Fachabteilung und Entwicklung sollen zusammenfallen. Praktisch heißt das: Glossare pflegen, unklare Synonyme streichen und in Code-Reviews prüfen, ob Klassen- und Methodennamen zur Sprache der Domäne passen.

Aggregates bündeln Entities und Value Objects unter einer Wurzel, die Konsistenzgrenzen definiert – Änderungen über die Aggregate-Grenze hinweg werden explizit modelliert (Events, Prozesse), statt versteckt über globale Updates.

Taktische Muster und Teststrategie

Kurz: Factories und Domain Services kommen zum Einsatz, wenn Logik nicht natürlich zu einer einzelnen Entity gehört – etwa die Prüfung, ob mehrere Bedingungen über Objekte hinweg erfüllt sind.

Factories und Domain Services kommen zum Einsatz, wenn Logik nicht natürlich zu einer einzelnen Entity gehört – etwa die Prüfung, ob mehrere Bedingungen über Objekte hinweg erfüllt sind. Specifications kapseln wiederkehrende Regeln („ist bestellbar?“) lesbar und wiederverwendbar.

Tests sollten Domänenverhalten ohne Framework-Noise abbilden: Given-When-Then auf Fachsprache, schnelle Unit-Tests für reine Domänenobjekte, und wenige, gezielte Integrationstests für Persistenz. So bleibt DDD kein Diagramm-Exerzitium, sondern tragfähige Codebasis.

Ergänzung: Lesetipps und nächste Schritte

Kurz: Wenn Sie DDD einführen wollen, lohnt sich ein Pilot-Bounded-Context mit klar begrenztem Scope – nicht die gesamte Legacy-Landschaft auf einmal.

Wenn Sie DDD einführen wollen, lohnt sich ein Pilot-Bounded-Context mit klar begrenztem Scope – nicht die gesamte Legacy-Landschaft auf einmal. Kombinieren Sie das mit einem Ubiquitous-Language-Glossar (ein gemeinsames Dokument, das sich im Sprint ändern darf) und Architektur-Reviews, die explizit fragen: „Welche Invariante schützen wir hier?“ So steigt die Wortzahl im Code nicht umsonst, sondern trägt zu weniger Missverständnissen zwischen Fachbereich und Entwicklung bei. Für vertiefte Architekturberatung und Umsetzung: Softwareentwicklung und IT-Beratung.

Häufig gestellte Fragen (FAQ)

Worum geht es in diesem Artikel zu „Domain-driven Design“?

Der Artikel fasst praxisnahe Aspekte zu Domain-driven Design zusammen und richtet sich an Entscheider und Umsetzende. Im Kern: Was ist Domain‑Driven Design (DDD)? Grundlagen, Modelle, ubiquitäre Sprache und Nutzen für wartbare, fachlich getriebene Softwarearchitektur.

Für wen sind die beschriebenen Inhalte besonders relevant?

Besonders relevant ist das für Organisationen in Softwareentwicklung, die zuverlässige Systeme, klare Schnittstellen und planbare Lieferungen brauchen – vom Mittelstand bis zu spezialisierten Fachabteilungen.

Wie lässt sich das Thema in eine IT- oder Digitalstrategie einordnen?

Einordnen lässt sich das Thema über passende Leistungsbausteine wie maßgeschneiderte Software und Begleitung: Architektur, Reviews und iterativer Rollout reduzieren Risiko und Nacharbeit. Ergänzend hilft eine Abstimmung mit IT-Beratung und Architektur, wenn mehrere Systeme oder Lieferanten beteiligt sind.

Welche nächsten Schritte sind sinnvoll, wenn Unterstützung gebraucht wird?

Für Architektur, Umsetzung oder ein zweites Expertenurteil lohnt sich ein unverbindliches Erstgespräch – inklusive Abgleich mit Ihrem Zeitplan und Ihren Schnittstellen.

Fachquellen und weiterführende Links

Kurz: Die folgenden unabhängigen Referenzen ergänzen die Einordnung zu den Themen dieses Artikels:

Die folgenden unabhängigen Referenzen ergänzen die Einordnung zu den Themen dieses Artikels:

• Bitkom – Verband der Digitalwirtschaft
• BSI – Bundesamt für Sicherheit in der Informationstechnik
• Europäische Kommission – Digitale Strategie
• MDN Web Docs (Mozilla)
• W3C – World Wide Web Consortium

<!-- v87-geo-append -->