Domain Driven Design (DDD) bedeutet, Software rund um die Fachdomäne zu entwerfen – nicht um Datenbanken, Frameworks oder Technik. Im Zentrum steht ein präzises, gemeinsam verstandenes Fachmodell (das Domain-Modell), das von Fachexperten und Entwicklern zusammen erarbeitet wird. Dieses Modell strukturiert den Code, die Sprache im Team und die Schnittstellen. Ziel: komplexe Geschäftslogik beherrschbar machen, Risiken reduzieren und Änderungen schneller und sicherer ausliefern.
Worum es bei DDD wirklich geht
DDD ist eine Arbeitsweise und Architekturhaltung. Du baust Software so, wie die Domäne denkt. Jede wichtige Regel, jeder Begriff – vom „Kundenkreditrahmen“ bis zur „Bestellfreigabe“ – findet sich als klarer Begriff und Operation im Code wieder. Statt „OrdersTable“ mit 50 Spalten gibt es ein lebendiges Modell: eine Bestellung mit Positionen, ein Zahlungsversuch, ein Lieferauftrag. Alles klar geschnitten, mit sauberen Grenzen (Bounded Contexts) und ohne implizite Magie.
Kernideen und Begriffe
Ubiquitous Language (Allgegenwärtige Sprache): Eine gemeinsame, präzise Fachsprache, die im Gespräch, in Tickets und im Code identisch verwendet wird. Sag im Code nicht „CustomerLimit“, wenn im Fachbereich „Kreditrahmen“ gesagt wird.
Domäne und Subdomänen: Das Geschäftsfeld (z. B. Handel) zerfällt in Teilbereiche: Kern (WettbewerbsvorteilEin Wettbewerbsvorteil ist der konkrete Grund, warum Kundinnen und Kunden dich einer Alternative vorziehen - dauerhaft und messbar. Das kann ein Preisvorteil sein, eine... Klicken und mehr erfahren), unterstützende und generische Subdomänen. DDD hilft, den Kern zu isolieren, damit dort Qualität und Geschwindigkeit zählen.
Bounded Context: Ein klar abgegrenzter Bedeutungsraum. „Kunde“ im Vertrieb meint etwas anderes als „Kunde“ in der Buchhaltung. Pro Kontext gibt es ein eigenes Modell, eigene Regeln und oft auch eigene Datenpersistenz. Die Verständigung zwischen Kontexten erfolgt über explizite Übersetzungen.
Context Map: Die Landkarte der Kontexte und ihrer Beziehungen. Zeigt, wo Übersetzungen nötig sind, wer von wem abhängig ist (z. B. Upstream/Downstream), und wo Schutzschichten eingerichtet werden.
Anti-Corruption Layer (ACL): Eine Schutzschicht, die ein sauberes Modell vor einem „fremden“ Modell bewahrt. Praktisch ist das eine Übersetzung: Außen kommt „Legacy-Sprache“ rein, innen bleibt Deine Ubiquitous Language sauber.
Taktische Muster: Bausteine im Code: Entity (hat Identität), Value Object (wertgleich, unveränderlich; z. B. Geldbetrag mit Währung), Aggregate (Konsistenzgrenzen und Invarianten), Domain Service (Fachlogik ohne natürliche Heimat), Repository (Lager für Aggregate), Domain Events („BestellungFreigegeben“ – etwas Bedeutendes ist passiert). Application Services orchestrieren Anwendungsfälle, enthalten aber keine Kernlogik.
Transaktions- und Konsistenzgrenzen: Ein Aggregate sichert Invarianten atomar. Zwischen Aggregaten akzeptierst Du oft „eventual consistency“ – dafür bekommst Du Skalierbarkeit und klare Grenzen.
Ein Beispiel aus der Praxis
Stell Dir einen Shop vor. In der Subdomäne „Bestellung“ ist ein Aggregate „Bestellung“ zuständig für Positionen, Gesamtsumme und Freigabe. Die Invariante: Eine Bestellung darf nur freigegeben werden, wenn alle Positionen verfügbar und die Summe gedeckt ist. Der Freigabe-Vorgang löst ein Domain Event „BestellungFreigegeben“ aus. Ein anderer Kontext „Zahlung“ hört zu und startet die Belastung. Wieder ein anderer Kontext „Logistik“ reagiert und erzeugt einen Lieferauftrag. Jeder Kontext hat sein eigenes Modell – kein gigantisches God-Object, keine allmächtige Tabelle.
In einem Kreditkontext sieht es ähnlich aus: Das Aggregate „Kreditlinie“ sichert, dass ein neuer Kredit nur unterhalb des genehmigten Rahmens liegt. Die Entscheidung ist im Modell verankert, nicht in einer UI-Validierung. Dadurch bleibt die Regel überall konsistent.
Praktisch vorgehen – Schritt für Schritt
Beginne mit Gesprächen. Setz Entwickler und Fachexperten zusammen und sammelt Begriffe, Regeln, Ausnahmen. Hört auf kleine Wörter („eigentlich“, „außer wenn“). Genau dort verstecken sich die kniffligen Invarianten. Visualisiere Abläufe und Ereignisse. Du brauchst kein perfektes Bild, nur genug, um das erste Modell zu schneiden.
Schneide Bounded Contexts. Prüfe: Wo ändern Begriffe ihre Bedeutung? Wo werden Regeln widersprüchlich? Lieber zwei kleine, klare Modelle als ein großes, verschwommenes. Zeichne die Context Map mit Richtungen (wer liefert, wer konsumiert) und definiere Schnittstellen. Wo ein starkes Legacy-System dominiert, setze eine Anti-Corruption Layer davor.
Definiere Aggregate mit klaren Invarianten. Formuliere sie als Sätze: „Eine Bestellung darf erst freigegeben werden, wenn …“. Dann implementiere Methoden, die diese Sätze widerspiegeln. Mach ValueWenn du schon einmal einen Sonnenaufgang erlebt hast, weißt du, wie die Welt langsam aus dem Dunkel in ein goldenes Licht getaucht wird. Diese... Klicken und mehr erfahren Objects wirklich unveränderlich und reich an Logik (z. B. Preis addieren, Währung prüfen), statt überall primitive Typen zu verstreuen.
Arbeite mit Domain Events. Benenne Ereignisse in der Fachsprache. Nutze sie zur Entkopplung zwischen Kontexten. Intern helfen sie Dir, Seiteneffekte gezielter zu behandeln. Akzeptiere dabei, dass nicht alles synchron passieren muss – solange fachliche Garantien stimmen.
Iteriere. DDD ist kein Big-Bang. Starte mit dem riskantesten Bereich, lerne, schärfe die Sprache, ziehe die Grenzen nach. Gute Modelle entstehen in Gesprächen und durch Feedback in echten Produktionssituationen.
Typische Fehler – und wie Du sie vermeidest
Zu große Aggregate: Wenn ein Aggregate ständig sperrt oder überall mitgeladen werden muss, ist es zu groß. Schmal schneiden, Invarianten prüfen, Rest per Event koordinieren.
Ubiquitous Language nur auf Folien: Wenn im Code andere Worte stehen als im Daily, kippt das Modell. Benennungen konsequent angleichen.
DDD ohne echte Domänenexperten: Ohne Fachinput modellierst Du Technik, nicht Geschäft. Hol die Fachseite regelmäßig ins Gespräch – mit Beispielen, Grenzfällen, echten Daten.
Kontexte als Ordnerstruktur statt als Bedeutungsräume: Ein Modul ist kein Bounded Context. Entscheidend ist, dass Begriffe drinnen konsistent sind und draußen übersetzt werden.
„Alles synchron, alles transaktional“: Harte Konsistenz über Kontextgrenzen klingt sicher, macht aber langsam und fragil. Besser: harte Invarianten innerhalb eines Aggregates, ansonsten klare fachliche Garantien und asynchrone Kopplung.
Wann DDD sinnvoll ist – und wann nicht
DDD lohnt sich, wenn Deine Geschäftslogik komplex, veränderlich oder geschäftskritisch ist. Wenn sich Regeln oft ändern, neue Produkte entstehen oder mehrere Teams parallel arbeiten, helfen klare Kontexte und eine starke Sprache enorm. Weniger sinnvoll ist DDD, wenn Du nur einfache CRUD-Verwaltung ohne komplexe Logik baust. Dann ist der Overhead höher als der Nutzen.
Häufige Fragen
Was bedeutet Domain Driven Design (DDD) in einem Satz?
Du modellierst Software entlang der Fachdomäne: gemeinsame Sprache, klare Grenzen (Bounded Contexts), fokussierte Bausteine (Aggregate, Entities, Value Objects) – damit komplexe Geschäftslogik verständlich, änderbar und zuverlässig bleibt.
Worin liegt der konkrete Nutzen für Unternehmen und Startups?
DDD reduziert Fehlentwicklungen und Abstimmungsaufwände, weil alle das gleiche meinen. Teams liefern schneller, weil klar ist, wo welche Regel lebt. Im Ergebnis: kürzere Time-to-Market, weniger Produktionsfehler, bessere Handhabung von Änderungen – besonders dort, wo Fachlogik Dein Wettbewerbsvorteil ist.
Was ist ein Bounded Context – und wie erkenne ich ihn?
Ein Bounded Context ist ein Bereich, in dem Begriffe und Regeln konsistent sind. Du erkennst ihn, wenn sich die Bedeutung eines Wortes ändert (Kunde im Vertrieb vs. in der Buchhaltung) oder wenn ein Team eigenständig liefern kann. Praktisch: Prüfe Änderungen – wenn eine Änderung ständig viele Teile mitzieht, ist die Grenze falsch; wenn Änderungen lokal bleiben, ist sie gut geschnitten.
Entity, Value Object, Aggregate – wie unterscheiden sie sich?
Entities haben Identität über die Zeit (z. B. Kunde #4711). Value Objects sind durch Werte definiert und unveränderlich (z. B. Geldbetrag 10,00 EUR). Ein Aggregate gruppiert Entities/Value Objects und definiert Invarianten und Transaktionsgrenzen. Nur die Aggregate-Wurzel wird von außen verändert, damit Regeln zentral bleiben.
Wie starte ich mit DDD ohne das ganze System umzubauen?
Wähle eine riskante oder häufig ändernde Subdomäne. Kläre Sprache und Regeln, schneide einen Bounded Context, setze eine Anti-Corruption Layer vor vorhandene Systeme und implementiere ein erstes Aggregate mit klaren Invarianten. Sammle Feedback, erweitere schrittweise. So minimierst Du Risiko und lernst schnell.
Brauche ich Microservices für DDD?
Nein. DDD ist unabhängig von MicroservicesMicroservices, das klingt zuerst einmal wie ein Wort, das nur Entwickler verstehen. Aber lass uns das mal runterbrechen: Stell dir vor, du hast eine... Klicken und mehr erfahren. Du kannst in einem MonolithenEs gibt in der digitalen Welt Begriffe, die irgendwie komplex und einschüchternd klingen – „Monolithische Architekturen“ ist so einer. Doch was genau steckt dahinter?... Klicken und mehr erfahren mit sauber getrennten Kontexten starten. Später lassen sich Kontexte als Services herauslösen – wenn es Sinn ergibt. Architektur folgt dem Modell, nicht umgekehrt.
Wie gehe ich mit Legacy-Systemen um, die mein Modell „verschmutzen“?
Platziere eine Anti-Corruption Layer zwischen Deinem sauberen Modell und dem Legacy-System. Diese Schicht übersetzt Begriffe und Datenformate. So bleibt Deine Ubiquitous Language intakt, während Du schrittweise modernisierst, ohne Big-Bang.
Wie sichere ich Konsistenz über Kontexte hinweg?
Harte Invarianten bleiben innerhalb eines Aggregates transaktional. Über Kontexte hinweg nutzt Du Domain Events und asynchrone Reaktionen. Plane fachliche Garantien („Lieferauftrag erst nach Bestellfreigabe“), setze Kompensationen für Fehlerfälle auf und beobachte Flows mit Monitoring. Eventual Consistency ist okay, wenn Fachregeln das erlauben.
Welche organisatorischen Änderungen unterstützt DDD?
DDD fördert autonome, domänenorientierte Teams entlang der Bounded Contexts. Fachseite und Tech arbeiten enger zusammen, Meetings werden kürzer, weil Begriffe klar sind. Übergaben reduzieren sich, weil Verantwortung entlang der Kontexte geschnitten ist – das beschleunigt Releases.
Ist DDD nicht zu „schwergewichtig“ für kleine Teams?
Der volle Werkzeugkasten ist groß, aber Du musst nicht alles nutzen. Schon zwei Dinge wirken sofort: gemeinsame Sprache konsequent im Code verwenden und klare Kontexte schneiden. Beides kostet wenig, bringt aber viel Struktur und Tempo – auch im kleinen Team.
Wie messe ich, ob DDD bei uns funktioniert?
Achte auf Indikatoren: Werden Änderungen lokaler? Sinkt die Zahl fachlicher Fehlerszenarien? Vergeht weniger Zeit von Idee zu Livegang? Können neue Kolleginnen und Kollegen die Domäne schneller verstehen? Wenn ja, ist Dein Modell tragfähig.
Welche typischen Antipatterns sollte ich vermeiden?
„Anemische“ Domänenmodelle (Logik in Services, Daten in Objekten), übergroße Aggregate, versteckte Coupling über gemeinsame Tabellen, inkonsistente Begriffe in Code und Gesprächen, „Alles-synchron“-Reflex. Gegenmittel: Invarianten im Aggregate ausdrücken, Kontexte klar trennen, Ereignisse nutzen, Sprache diszipliniert pflegen.
Wie gehe ich mit Berichts- und Lesemodellen um?
Trenne Schreib- und Lesemodelle dort, wo es hilft: Das Domänenmodell optimiert Regeln und Konsistenz, das Lesemodell optimiert Abfragen und Darstellung. Denke in Projektionen, die aus Domain Events gespeist werden. So bleibt die Fachlogik schlank und Reports werden schnell.
Fazit und Empfehlung
DDD ist kein Dogma, sondern eine Einladung, Software so zu bauen, wie Dein Geschäft wirklich tickt. Fang klein an: Sprache klären, Kontexte schneiden, ein erstes Aggregate mit harter Invariante umsetzen. Beobachte, lerne, justiere. Wenn Du dabei Sparring brauchst oder eine zweite Perspektive auf Deine Kontextlandkarte, kann Berger+Team Dich pragmatisch unterstützen – mit Fokus auf klare Begriffe, saubere Schnitte und Lösungen, die im Alltag tragen.
