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 Arbeitsprozesse und der Fachsprache 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.

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

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

Infobox Ubiquitous Language

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 auf 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:

1. Carola Lilienthal, Henning Schwentner: Domain-Driven Transformation, dpunkt 2023.
2. Melvin E. Conway: How Do Committees Invent? In: F. D. Thompson Publications, Inc. (Hrsg.): Datamation. Band 14, Nr. 5, April 1968, S. 28–31
3. Dan North: Introducing BDD. Better Software Magazin, März 2006
4. Simon Wardley. My basics for business strategy. Medium. Hacker Noon, Mai 2017
5. Matthew Skelton, Manuel Pais: Team Topologies: Organizing Business and Technology for Fast Flow of Value,IT Revolution, 2nd Edition, 2025

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