Domain-Driven Design: Missverständnisse vermeiden, um Investition zu sichern
Ein Artikel von Carola Lilienthal
Softwareentwicklung ist ein Prozess, bei dem es zu vielen Missverständnissen kommen kann: Die späteren Anwender:innen sprechen ihre eigene fachliche Sprache. Das Softwareentwicklungsteam kommt aus einer technischen Welt und soll etwas schaffen, was es noch nicht gibt – innovativ und technisch auf dem neusten Stand. Ein Scheitern ist also durchaus möglich!
„It’s developers’ (mis)understanding,
not domain experts’ knowledge,
that gets released in production.”
Alberto Brandolini, Erfinder des Event Stormings, bringt damit auf den Punkt, warum das Wissen über Domain-Driven Design (DDD) absolut essenziell ist für alle am Softwareentwicklungsprozess Beteiligten. Bei der Softwareentwicklung muss es uns gelingen, die Domäne tiefgehend zu verstehen und das Domänenwissen bis in die Software zu tragen.
Nur so können wir Softwaresysteme bauen, die zu 100% zur Aufgabe passen, die Domänenexpert:innen an das System stellen. Einerseits verbessert und beschleunigt domänengetriebene Software die Arbeitsprozesse. Andererseits können wir die Software im Einklang mit der Domäne über viele Jahre weiterentwickeln, denn die Domäne ist in der Regel stabiler als die von uns eingesetzte Technologie.
DDD ist eine Methode, die genau diese domänengetriebene Herangehensweise in den Vordergrund stellt (vgl. Lilienthal 2023): Gemeinsam mit den Domänenexpert:innen erarbeitet sich das Entwicklungsteam in einem agilen Prozess das Verständnis der Prozesse und Sprache in der Domäne. Die für Anforderungsermittlung verwendeten Techniken werden in DDD unter dem Begriff Collaborative Modelling zusammengefasst. Das dabei erworbene Verständnis wird in eine Context Map (Abb. 1), in Bounded Contexts, in der Ubiquitious Language, in Domänenmodellen überführt und schließlich in Sourcecode umgesetzt. Im Folgenden betrachten wir diese Schritte genauer.
Abb. 1: Zusammenhang Domäne, Softwaresystem und Teamstruktur
Collaborative Modelling und strategisches Design
Collaborative Modelling wird auf unterschiedlicher „Flughöhe“ während des gesamten Entwicklungsprojekts eingesetzt. Wir starten mit dem big picture: einer Gesamtschau der Domäne und analysieren die übergreifenden Arbeitsprozesse. Mit den Analyseergebnissen können wir das Strategic Design aus DDD beginnen. Dabei arbeiten wir verschiedene Subdomänen für unsere Domäne heraus und bewerten, wie wichtig diese für unsere Domäne sind (Core, Supporting, Generic Subdomains). Diese Bewertung hilft dem Entwicklungsteam und dessen Management, zu entscheiden, wo wir unsere begrenzten Ressourcen investieren und wo sich der Einkauf von Fremdsoftware lohnt.
Abb. 2: Beispiel einer Context Map aus der Fachdomäne Kino
Um den Gesamtüberblick über die Architektur zu bekommen, entwickeln wir in diesem Schritt die sog. Context Map, in der wir die Subdomänen und ihre Beziehungen zueinander auf Bounded Contexts abbilden (Abb. 2). Die Context Map gibt die Struktur unserer Software vor, mit den Bounded Contexts als fachliche Module und ihren mit dem Context Mapping herausgearbeiteten unterschiedlichen Arten von Schnittstellen. So bekommen wir eine aus der Domäne getriebene Architektur, die zusätzlich auch Grundlage unserer Teamaufteilung sein kann (vgl. Conway 1968).
Ubiquitous Language und taktisches Design
In jedem Bounded Context wird die Ubiquitous Language – die gemeinsame Fachsprache – herausgearbeitet und das Domänenmodell entwickelt, mit dem die Ubiquitous Language in den Sourcecode überführt wird.
Ein System, dass nach DDD gebaut ist, besteht demnach aus mehreren Modulen mit jeweils unterschiedlichen Domänenmodellen, wobei jedes genau auf die Fachlichkeit seines Bounded Contexts zugeschnitten ist und so seine Subdomäne möglichst präzise den Punkt bringt.
Für die Konstruktion des Domänenmodells gibt uns DDD mit dem Tactical Design Anleitung. Dabei unterscheidet DDD fünf Arten von Klassen, die jeweils nach einem bestimmten Muster programmiert und miteinander verbunden werden: Entity, Domain Value, Service, Repository, Factory. Eine Technik aus dem Collaborative Modelling hilft uns, den richtigen Schnitt für die Klassen des Domänenmodells zu finden. Mit Example Mapping aus Behavior-Driven Development (BDD; vgl. North 2006) lassen sich Szenarien für fachlich getriebene Akzeptanztests herauszuarbeiten um die fachlichen Schnittstellen der Klassen und deren Zusammenarbeit modellieren.
Fazit und Ausblick
Wie die meisten lebendigen Methoden, entwickelt sich auch DDD ständig weiter. Aktuell wird in der DDD-Community über Team Topologies (vgl. Skelton 2025) und Wardley Maps (vgl. Wardley 2017) diskutiert. Team Topologies betrachtet die unterschiedlichen Arten von Teams in Organisationen. hat unseren Blick auf die Teamorganisation über die Stream-Aligned Teams, die einen Bounded Context umsetzen, hinaus geweitet, so dass wir uns Gedanken über Plattform, Enabling und Complicated Subsystem machen können. Mit Wardley Maps sind wir in der Lage, strategische Entscheidungen für die Weiterentwicklung unserer Softwarelösungen für alle beteiligten Ebenen gleichermaßen verständlich und sichtbar zu machen. Dadurch können wir mit der Management-Ebene über die weitere strategische Planung sprechen.
Setzt man all diese Techniken und Konzepte aus DDD im Entwicklungsprozess ein und behält bei der Weiterentwicklung des Systems die domänengetriebene Perspektive bei, wird sich die Investition in Software langfristig lohnen. Missverständnisse über die zu unterstützende Domäne werden mit DDD vermieden und es entsteht eine Software, die ihre Anwender:innen perfekt unterstützt.
Literatur
- Carola Lilienthal, Henning Schwentner: Domain-Driven Transformation, dpunkt 2023.
- Melvin E. Conway: How Do Committees Invent? In: F. D. Thompson Publications, Inc. (Hrsg.): Datamation. Band 14, Nr. 5, April 1968, S. 28–31
- Dan North: Introducing BDD. Better Software Magazin, März 2006
- Simon Wardley. My basics for business strategy. Medium. Hacker Noon, Mai 2017
- Matthew Skelton, Manuel Pais: Team Topologies: Organizing Business and Technology for Fast Flow of Value,IT Revolution, 2nd Edition, 2025
Die Autorin
Dr. Carola Lilienthal ist Geschäftsführerin der WPS – Workplace Solutions GmbH und prüft im Auftrag ihrer Kunden regelmäßig die Qualität von Softwarearchitekturen. Ihre Erfahrungen hat sie in den Büchern „Langlebige Softwarearchitekturen“ und „Domain-Driven Transformation“ zusammengefasst.
Appendix
Ubiquitious Language
DDD fordert, dass alle Beteiligten an einem Softwareprojekt eine gemeinsame fachliche Sprache entwickeln, die sog. Ubiquitous Language (allgegenwärtige Sprache). Diese gemeinsame Sprache soll auf der Fachsprache der Fachexpert:innen basieren, nicht auf der technischen Sprache der Entwickler:innen. Ziel ist es, die Fachsprache so zu standardisieren, dass die Fachbegriffe aus dem Problemraum (Domäne) im Lösungsraum (Software) ihre Entsprechung finden können. DDD empfiehlt, dass diese gemeinsame Sprache während der Laufzeit eines Projekts überall verwendet wird: im Gesprochenen, im Geschriebenen, in Diagrammen und eben auch im Code.
Bounded Context
Im Softwaresystem sollte es pro Subdomäne einen Bounded Context geben, der einen Teil des Sourcecodes umfasst und ein eigenes Datenbankschema besitzt. In klassischer Softwarearchitektur würde man die Bounded Contexts als Module oder Komponenten bezeichnen. Allerdings ist es aus DDD-Sicht entscheidend, dass die Bounded Contexts fachlich geschnitten sind.
Wardley Mapping
Eine Wardley Map ist eine Darstellung der Landschaft, in der ein Unternehmen tätig ist. Sie besteht aus einer Wertschöpfungskette – also Aktivitäten zur Erfüllung der Benutzer:innen-Anforderungen; die im Vergleich zur Entwicklung – also die Veränderung einzelner Aktivitäten im Laufe der Zeit aufgrund des Wettbewerbs zwischen Angebot und Nachfrage; grafisch dargestellt ist.
Context Map
Je größer die Domäne ist und je größer die Software wird, desto mehr fachliche Kontexte wird es geben. Um hier die Übersicht zu behalten, gibt DDD uns das Mittel der Context Map an die Hand – eine Landkarte der fachlichen Kontexte.
Conways Law
besagt, dass die Architektur eines Systems die Kommunikationsstruktur der Organisation widerspiegelt, die es entwickelt hat. Vereinfacht formuliert, ist die Struktur des Systems, das entwickelt wird, von der Struktur der Teams abhängig, die daran arbeiten.
Team Topologies
ist ein Konzept und Rahmenwerk, das einen Leitfaden für die Organisation und Entwicklung von Teams innerhalb einer Organisation bietet, um Softwareprodukte oder ‑dienste effektiv zu entwickeln und bereitzustellen. Team Topologies wurde durch das gleichnamige Buch von Matthew Skelton und Manuel Pais aus dem Jahre 2019 bekannt.
Stream-Aligned Team
schaffen den Wert für die Kund:innen entlang des Value Stream. Sie sind cross-funktional zusammengesetzt, damit sie mit diesem Kompetenzmix schnell signifikante Inkremente liefern können. Sie haben einen klaren und fokussierten Auftrag und sind für den gesamten Lebenszyklus ihrer Produkte verantwortlich, von der Entwicklung über die Bereitstellung bis zum Betrieb.
Teilen Sie diesen Artikel:
Zum Thema passende Artikel
