Dieter Baier

Domain Driven Design
1.1
04/2026
Der Schlüssel für eine evolutionäre Architektur ist die Fähigkeit, die Domäne zu verstehen und zu modellieren. Domain-Driven Design (DDD) bietet einen Ansatz, um dies zu erreichen, indem es die Zusammenarbeit zwischen Domänenexperten und Entwicklern fördert und eine gemeinsame Sprache schafft, um komplexe Geschäftsprobleme zu lösen.
— nach Allen Holub

Kultur und Werte

DDD ist mehr als nur eine Sammlung von Techniken und Mustern.

Es ist eine Denkweise, die auf einer engen Zusammenarbeit zwischen Domänenexperten und Entwicklern basiert. Es erfordert eine Kultur des Lernens, der Offenheit und der kontinuierlichen Verbesserung.

Es ermutigt Teams, sich auf die Bedürfnisse der Benutzer zu konzentrieren und Lösungen zu entwickeln, die echten Mehrwert bieten.

Implizite Annahmen werden zu explizitem Wissen

DDD hilft dabei, implizites Wissen über die Domäne in explizites Wissen umzuwandeln.

Durch die Zusammenarbeit zwischen Domänenexperten und Entwicklern können Teams ein tiefes Verständnis der Geschäftsprozesse und -regeln entwickeln, was zu besseren Softwarelösungen führt.

Ohne Zugriff auf Fachwissen, kein DDD

DDD erfordert den Zugriff auf Domänenexperten, um ein tiefes Verständnis der Geschäftsprozesse und -regeln zu entwickeln.

Ohne diesen Zugriff ist es schwierig, die Prinzipien von DDD effektiv anzuwenden.

Gemeint sind hiermit nicht nur die klassischen Domänenexperten, sondern auch alle anderen Stakeholder, die wertvolles Wissen über die Domäne haben, wie z.B. Endbenutzer, Kunden oder andere Interessengruppen.

Auch eine Bereichssekretärin, die seit Jahren in einem Unternehmen arbeitet, kann wertvolles Wissen über die Abläufe und Prozesse haben, das für die Entwicklung von Softwarelösungen von entscheidender Bedeutung sein kann.

Besonders wichtige Rollen sind:

  • Entwickler:innen

  • Fachexpert:innen

Ein gemeinsames Verständnis der Domäne aufzubauen, erfordert niedrige Einstiegshürden für die Modellierung

Um ein gemeinsames Verständnis der Domäne aufzubauen, ist es wichtig, niedrige Einstiegshürden für die Modellierung zu schaffen.

Jeder Wissensträger sollte in der Lage sein, seine Ideen und Erkenntnisse in das Modell einzubringen, ohne sich mit komplexen technischen Details bezüglich der Modellierungssprache auseinandersetzen zu müssen.

Identifizieren von fachlichen Grenzen (Bounded Contexts)

Das Identifizieren von fachlichen Grenzen, auch bekannt als Bounded Contexts, ist ein wichtiger Schritt im DDD-Prozess.

Man befindet sich beim Identifizieren von fachlichen Grenzen im Lösungsraum und nicht mehr im Problemraum, da es darum geht, die Softwarearchitektur so zu gestalten, dass sie gut mit der Domäne und den Geschäftsprozessen übereinstimmt.

Es hilft dabei, die Komplexität der Domäne zu reduzieren und ermöglicht es Teams, sich auf spezifische Teile der Domäne zu konzentrieren, um bessere Lösungen zu entwickeln.

DDD stellt einen methodischen Baukasten bereit, um diese fachlichen Grenzen zu identifizieren und zu modellieren, was zu einer besseren Softwarearchitektur führt.

Ein Bounded Context ist ein spezifischer Bereich der Domäne, in dem bestimmte Geschäftsprozesse und -regeln gelten.

Es ist eine Art "Blase", in der ein bestimmtes Modell der Domäne gilt und in der die Kommunikation zwischen verschiedenen Teilen der Softwarelösung stattfindet.

Bounded Contexts sollten mit der zugehörigen Subdomäne übereinstimmen

Es ist wichtig, dass die Bounded Contexts mit den zugehörigen Subdomänen übereinstimmen, um sicherzustellen, dass die Softwarearchitektur gut mit der Domäne und den Geschäftsprozessen übereinstimmt.

Vorteile, wenn die Grenzen des Bounded Contextes (Lösungsraum) mit den Grenzen der Subdomäne (Problemraum) übereinstimmen:

  • Software und Domänen entwickeln sich im Einklang, was zu einer besseren Softwarelösung führt, die den Bedürfnissen der Benutzer entspricht und sich an die sich ändernden Anforderungen anpassen kann.

  • Mehr Arbeit bleibt innerhalb eines Teams, teamübergreifende Kommunikation wird reduziert, was die Effizienz und die Qualität der Softwarelösung erhöht.

  • Autonome, crossfunktionale Teams mit Ende-zu-Ende Verantwortung werden möglich, was die Motivation und die Produktivität der Teams erhöht.

  • Architektur und Teamgröße können linear mit der Komplexität der Subdomäne wachsen, was die Wartbarkeit und Erweiterbarkeit der Softwarelösung verbessert.

Kontextübergreifende Kommunikation

Die Kommunikation zwischen verschiedenen Bounded Contexts ist entscheidend, um sicherzustellen, dass die verschiedenen Teile der Softwarelösung nahtlos zusammenarbeiten.

DDD bietet verschiedene Muster und Techniken, um die Kommunikation zwischen Bounded Contexts zu erleichtern, wie z.B. Anticorruption Layers oder Shared Kernels.

Kontinuierliches Refactoring

DDD betont die Bedeutung von kontinuierlichem Refactoring, um sicherzustellen, dass die Softwarelösung immer an die sich ändernden Anforderungen und Erkenntnisse angepasst wird.

Durch kontinuierliches Refactoring können Teams sicherstellen, dass die Softwarelösung immer auf dem neuesten Stand bleibt und den Bedürfnissen der Benutzer entspricht.

Ziel: Austrucksstarke, flexible Softwarelösungen

Das Ziel von DDD ist es, ausdrucksstarke und flexible Softwarelösungen zu entwickeln, die den Bedürfnissen der Benutzer entsprechen und sich an die sich ändernden Anforderungen anpassen können.

Durch die Anwendung der Prinzipien von DDD können Teams Softwarelösungen entwickeln, die nicht nur funktional, sondern auch wartbar und erweiterbar sind, was langfristig zu einem erfolgreichen Softwareprojekt beiträgt.

Ausrucksstarke Softwarelösungen und lose gekoppelte Komponenten

Ausdrucksstarke Softwarelösungen sind solche, die die Geschäftsprozesse und -regeln klar und verständlich darstellen, was es einfacher macht, die Software zu verstehen und zu warten.

Lose gekoppelte Komponenten sind solche, die unabhängig voneinander entwickelt und geändert werden können, was die Flexibilität und Wartbarkeit der Software erhöht.

Durch die Anwendung der Prinzipien von DDD können Teams Softwarelösungen entwickeln, die sowohl ausdrucksstark als auch lose gekoppelt sind, was zu einer besseren Softwarearchitektur führt.

DDD bietet die Offenheit in Richtung anderer Paradigmen

DDD ist nicht auf ein bestimmtes Paradigma beschränkt, sondern bietet die Offenheit, verschiedene Paradigmen und Technologien zu integrieren (wie z.B. DevOps, Agile, Enterprise Architecture oder auch Organisationsentwicklung), um die besten Lösungen für die spezifischen Anforderungen der Domäne zu entwickeln.

Durch die Anwendung der Prinzipien von DDD können Teams Softwarelösungen entwickeln, die nicht nur funktional, sondern auch flexibel und anpassungsfähig sind, was langfristig zu einem erfolgreichen Softwareprojekt beiträgt.

DDD ist eine Reise, kein Ziel

DDD ist eine kontinuierliche Reise, die ständiges Lernen, Anpassen und Verbessern erfordert.

Es ist kein einmaliges Ziel, sondern ein fortlaufender Prozess, der es Teams ermöglicht, sich ständig weiterzuentwickeln und bessere Softwarelösungen zu entwickeln, die den Bedürfnissen der Benutzer entsprechen und sich an die sich ändernden Anforderungen anpassen können.

DDD gibt keinen Hinweis auf einer Deployment Architektur oder Teamorganisation

DDD gibt keinen spezifischen Hinweis darauf, wie die Deployment-Architektur oder die Teamorganisation aussehen sollte. Es konzentriert sich vielmehr auf die Modellierung der Domäne und die Zusammenarbeit zwischen Domänenexperten und Entwicklern, um eine gemeinsame Sprache zu schaffen und komplexe Geschäftsprobleme zu lösen.

Die Entscheidung über die Deployment-Architektur und die Teamorganisation hängt von den spezifischen Anforderungen der Domäne, den verfügbaren Ressourcen und den Präferenzen des Teams ab.

DDD bietet jedoch Prinzipien und Muster, die bei der Gestaltung der Softwarearchitektur und der Teamorganisation berücksichtigt werden können, um sicherzustellen, dass sie gut mit der Domäne und den Geschäftsprozessen übereinstimmen.

Domänen spiegeln wieder, wie eine Organisation ihre Tätigkeits- und Fachwissensbereiche wahrnimmt

Eine Domäne ist ein spezifischer Bereich oder Kontext, in dem bestimmte Geschäftsprozesse und -regeln gelten. Es ist der Bereich, in dem die Softwarelösung entwickelt wird und in dem die Geschäftsprobleme gelöst werden sollen.

  • Eine Domäne ist etwas, das man sich auf die Fahnen schreibt

  • Eine Domäne ist etwas, wovon man explizites Fachwissen hat

  • Eine Domäne ist etwas, worin man eine bestimmte Arbeitsweise hat

A Domain in the broad sense, is what an organization does and the world it does it in. …​ Each kind of organization has its own unique realm of know-how and way of doing things. That realm of understanding and its methods for carrying out its operations is its domain.
— Vaughn Vernon

Problemdomäne

Die Problemdomäne ist der Bereich, in dem die Geschäftsprobleme und -anforderungen liegen, die durch die Softwarelösung gelöst werden sollen.

Es ist der Bereich, in dem die Geschäftsprozesse und -regeln definiert sind, die die Softwarelösung unterstützen soll.

  • Im Kontext von DDD ist die Domäne KEIN direktes Abbild der Aufbauorganisation oder der Teamorganisation, sondern vielmehr ein Abbild der Geschäftsprozesse und -regeln, die in der Softwarelösung modelliert werden sollen.

  • Es ist wichtig, die Domäne so zu modellieren, dass sie die Geschäftsprozesse und -regeln klar und verständlich darstellt, um sicherzustellen, dass die Softwarelösung den Bedürfnissen der Benutzer entspricht und sich an die sich ändernden Anforderungen anpassen kann.

Es gibt unterschiedliche Arten von Subdomänen

Es gibt verschiedene Arten von Subdomänen, die in einer Domäne identifiziert werden können, wie z.B. Kern-Subdomänen, unterstützende Subdomänen und generische Subdomänen.

Jede Art von Subdomäne hat unterschiedliche Anforderungen und Herausforderungen, die bei der Modellierung und Entwicklung der Softwarelösung berücksichtigt werden müssen.

  • Kern-Subdomänen (Core Subdomain) sind diejenigen, die den größten Mehrwert für die Benutzer bieten und die wichtigsten Geschäftsprozesse und -regeln repräsentieren.

    Heuristik: hohe Differenzierung am Markt, hohe Komplexität, hohe strategische Bedeutung.

    Das muss richtig gut sein. Heißt: eigenes Team, sehr hoher Qualitätsanspruch, kontinuierliches Refactoring, hohe Investitionen in die Wartbarkeit und Erweiterbarkeit.

  • Unterstützende Subdomänen (Supporting Subdomain) sind diejenigen, die die Kern-Subdomänen unterstützen und ergänzen, aber nicht den gleichen Mehrwert bieten.

    Heuristik: alles was nicht Kern- oder generische Subdomäne ist, ist eine unterstützende Subdomäne.

    Diese Subdomänen sollten so gestaltet werden, dass sie die Kern-Subdomänen effektiv unterstützen, ohne zu viel Komplexität oder Wartungsaufwand zu verursachen.

  • Generische Subdomänen (Generic Subdomain) sind diejenigen, die allgemeine Funktionen oder Dienste bereitstellen, die von verschiedenen Teilen der Domäne genutzt werden können, aber nicht spezifisch für die Geschäftsprozesse und -regeln der Domäne sind.

    Heuristik: keine Differenzierung am Markt, niedrige Komplexität, niedrige strategische Bedeutung.

    Diese Subdomänen können oft durch Standardsoftware oder externe Dienste abgedeckt werden, was es ermöglicht, sich auf die Kern-Subdomänen zu konzentrieren und Ressourcen effizienter zu nutzen.

Strategisches DDD hilft dabei die Softwarearchitektur nach der Geschäftsdomäne und den Teams auszurichten

Strategisches DDD konzentriert sich auf die Identifizierung von Bounded Contexts und die Gestaltung der Softwarearchitektur, um sicherzustellen, dass sie gut mit der Domäne und den Geschäftsprozessen übereinstimmt.

Durch die Anwendung der Prinzipien von strategischem DDD können Teams sicherstellen, dass die Softwarearchitektur gut mit der Domäne und den Geschäftsprozessen übereinstimmt, was zu einer besseren Softwarelösung führt, die den Bedürfnissen der Benutzer entspricht und sich an die sich ändernden Anforderungen anpassen kann.

EventStorming: Ein Ansatz zur Domänenmodellierung

EventStorming ist eine kollaborative Workshop-Methode, die darauf abzielt, ein tiefes Verständnis der Geschäftsprozesse und -regeln zu entwickeln, indem sie die Teilnehmer dazu ermutigt, die Ereignisse, die in der Domäne auftreten, zu identifizieren und zu modellieren.
— nach Alberto Brandolini

EventStorming Glossary Cheat Sheet der DDD-Crew

Kann auch gut für ein Onboarding genutzt werden, um neue Teammitglieder schnell in die Domäne einzuführen und ein gemeinsames Verständnis zu entwickeln.

Big Picture Event Storming

Das Big Picture Event Storming ist eine Methode, um ein umfassendes Verständnis der Geschäftsprozesse und -regeln zu entwickeln, indem alle relevanten Ereignisse in der Domäne identifiziert und modelliert werden.

Es geht nicht darum, ein detailliertes Modell zu erstellen, sondern vielmehr darum, ein gemeinsames Verständnis der Domäne zu entwickeln und die wichtigsten Ereignisse und Zusammenhänge zu identifizieren. Die Detaillierung erfolgt in späteren Workshops, wie z.B. dem Process Level Event Storming oder dem Design Level Event Storming.

Folgende Schritte sind typisch für einen Big Picture Event Storming Workshop:

  1. Vorbereitung: Der Moderator bereitet den Workshop vor, indem er die Teilnehmer einlädt, den Raum (ein Raum, in dem man sich frei bewegen können und eine freie Wand von 4 bis 5 Metern bereitstellt) vorbereitet und die notwendigen Materialien bereitstellt.

  2. Ereignisse identifizieren (Chaotic Exploration): Die Teilnehmer identifizieren die Ereignisse, die in der Domäne auftreten, und schreiben sie auf Haftnotizen.

  3. Ereignisse gruppieren: Die Teilnehmer gruppieren die Ereignisse, um Muster und Zusammenhänge zu erkennen.

  4. Pivotal Events identifizieren: Die Teilnehmer identifizieren die wichtigsten Ereignisse, die den Ablauf der Geschäftsprozesse maßgeblich beeinflussen.

  5. Ereignisse ordnen: Die Teilnehmer ordnen die Ereignisse in einer zeitlichen Reihenfolge, um den Ablauf der Geschäftsprozesse zu verstehen.

  6. Ereignisse analysieren: Die Teilnehmer analysieren die Ereignisse, um die Geschäftsregeln und -prozesse zu verstehen und zu dokumentieren.

Subdomains identifizieren

Die Teilnehmer identifizieren die Subdomains, indem sie die Ereignisse gruppieren und die Zusammenhänge zwischen den Ereignissen analysieren. Subdomains sind Bereiche der Domäne, die bestimmte Geschäftsprozesse oder -regeln repräsentieren und können als Grundlage für die weitere Detaillierung in späteren Workshops dienen.

Heuristiken zur Identifikation von Subdomains:

  • Pivotal Events: Ereignisse, die den Ablauf der Geschäftsprozesse maßgeblich beeinflussen, können auf wichtige Subdomains hinweisen.

  • Swimlanes: Das Einführen von Swimlanes (vertikale oder horizontale Linien) kann helfen, die Ereignisse in verschiedene Bereiche zu gruppieren und so Subdomains zu identifizieren.

  • Kohäsion: Ereignisse, die eng miteinander verbunden sind und ähnliche Geschäftsprozesse oder -regeln repräsentieren, können auf eine gemeinsame Subdomain hinweisen.

  • Purpose: Ereignisse, die einen bestimmten Zweck oder ein bestimmtes Ziel verfolgen, können auf eine Subdomain hinweisen, die sich auf diesen Zweck oder dieses Ziel konzentriert.

Die Identifikation von Subdomains ist ein wichtiger Schritt im EventStorming, da sie die Grundlage für die weitere Detaillierung in späteren Workshops bildet. Subdomains helfen dabei, die Komplexität der Domäne zu reduzieren und ein besseres Verständnis der Geschäftsprozesse und -regeln zu entwickeln.

Domain Storytelling

egon.io

Domain Storytelling ist eine Methode, um ein tiefes Verständnis der Geschäftsprozesse und -regeln zu entwickeln, indem die Teilnehmer dazu ermutigt werden, die Geschäftsprozesse in Form von Geschichten zu erzählen und zu modellieren. Es ist eine kollaborative Methode, die darauf abzielt, ein gemeinsames Verständnis der Domäne zu entwickeln und die Kommunikation zwischen Domänenexperten und Entwicklern zu verbessern.
— nach Markus Voelter

Eine Domain Story ist eine narrative Beschreibung eines Geschäftsprozesses oder einer Geschäftsregel, die von einem Domänenexperten erzählt wird.

Sie enthält Informationen über die beteiligten Akteure, die Schritte des Prozesses und die Entscheidungen, die getroffen werden müssen in einfachen Sätzen und ohne technische Details (Subjekt, Prädikat, Objekt).