© rawpixel / 123RF.com

Auf den ersten Blick scheinen DDD als Softwarearchitekturansatz und Agilität als Prozessmodell unterschiedliche Bereiche der Softwareentwicklung abzudecken. Tatsächlich erzeugen sie nicht nur Synergien, sondern streben teilweise sogar dasselbe an.

Schon der Begriff Domain-driven Design sagt, worum es geht: Die Domäne – also die Fachlichkeit – soll das Design treiben. Mit Design bezeichne dabei die gesamte Gestaltung der Software, von der Codeebene bis hin zur Architektur und dem Zusammenspiel der beteiligten Entwicklungsteams. Damit diese konsequente Orientierung an der Domäne überhaupt funktioniert, müssen alle Beteiligten sich austauschen, vor allem Fachexperten und Entwickler.

Schließlich können die Domänenkonzepte nur dann die Grundlage der Entwicklung bilden, wenn alle Beteiligten sie klar kommunizieren. Die Entwickler kennen die Domäne sonst nicht im notwendigen Detailgrad, das tun ausschließlich die Fachexperten. Genau hier findet sich schon der erste Zusammenhang mit Agilität. Zu den Prinzipien des agilen Manifests [1] gehört: “Fachexperten und Entwickler müssen während des Projekts täglich zusammenarbeiten.” Nur mithilfe solcher Maßnahmen lässt sich Domain-driven Design überhaupt umsetzen.

Praxis statt Theorie

Anfangs umfasste die DDD-Bewegung vor allem Ideen zur Strukturierung von Code oder Softwaresystemen. Diese mit Fachexperten zu diskutieren, fällt schwer, da ihnen häufig die technischen Grundlagen dazu fehlen. Konzepte wie Klassen oder Module gehören eben nicht zum Allgemeinwissen. Es kann allerdings nicht die Voraussetzung für die gemeinsame Arbeit sein, zunächst Fachexperten in diesem Bereich auszubilden – dazu liegt die Hürde schlicht zu hoch. Zu Domain-driven Design zählen inzwischen aber eine Menge von kollaborativen Modellierungstechniken. Deren Ziel besteht darin, durch gemeinsame Arbeit an Artefakten das Verständnis für die Domäne zu stärken. Die Artefakte kommen jedoch nicht direkt zur Strukturierung der Software zum Einsatz, sondern dienen ausschließlich dazu, die Domäne genauer zu erläutern.

Ein bekanntes Beispiel für kollaborative Modellierung ist Event Storming, bei dem alle am Projekt Beteiligte mithilfe von Post-its selbst komplexe Geschäftsabläufe erschließen [2]. Auf jedem Zettel notieren Sie ein Event (Ereignis) aus der Domäne, beispielsweise Bestellung eingegangen. Dadurch klärt sich der Ablauf der Prozesse. Das Verfahren funktioniert in der Praxis auch für komplexe Prozesse, Sie brauchen nur genügend Platz für die Klebezettel.

Da das Konzept auf dieser Ebene nicht sonderlich kompliziert ausfällt, sollten alle Beteiligten solche Post-its schreiben können. Später lassen sich weitere Informationen auf weiteren Zetteln ergänzen. Eine andere Technik mit demselben Ziel, bei der Sie einen Ablauf eines Geschäftsprozesses grafisch darstellen, heißt Domain Storytelling [3]. So ergänzt DDD die agile Idee der Zusammenarbeit von Fachexperten und Entwicklern um konkrete Techniken.

DDD erzwingt Iterationen

Domain-driven Design setzt sich ein Modell der Domäne zum Ziel, das in ausführbarem Code implementiert ist. Die Logik im Code bildet die Realität ab, etwa indem sie die Kosten für eine Lieferung oder deren aktuellen Zustand abbildet. Dabei geht DDD davon aus, dass trotz aller Bemühungen dieses Modell nie perfekt sein wird, wie Eric Evans schon 2003 in einem der ersten Bücher über DDD schrieb [4].

Im Kern besteht die Aufgabe der Teams bei DDD darin, die Fachlichkeit zu verstehen (Knowledge Crunching). Dahinter steckt ein Lernprozess, der seine Zeit in Anspruch nimmt. Dementsprechend repräsentiert das Modell im Code ausschließlich das jeweils aktuelle Verständnis der Entwickler und Entwicklerinnen, mit allen Fehlern und Ungenauigkeiten. Die Herausforderung bei der Softwareentwicklung liegt also nicht im Programmieren des Codes, sondern darin, zu verstehen, was es zu programmieren gilt.

Zusätzlich erreicht das Modell im Code keine Perfektion, weil sich die Fachlichkeit wandelt. Ändern sich beispielsweise die Geschäftsprozesse, müssen Sie Ihre Software anpassen. Umgekehrt beeinflusst das Einführen der Software die Fachlichkeit: Setzen Sie sich beim Modellieren mit ihr auseinander und reflektieren sie, erkennen Sie dabei gegebenenfalls Optimierungspotenziale, die im alltäglichen Trott untergehen. Um diese Potenziale wie die Möglichkeit zur Automatisierung zu nutzen, müssen Sie sowohl die Fachlichkeit als auch die Software modifizieren.

Wenn sich die Fachlichkeit während der Entwicklung verändert, müssen Sie die Software in Iterationen erstellen. So reagieren Sie durch eine neue Iteration mit einer neuen Version der Software auf etwaige Änderungen. Um das Lernen aller zu gewährleisten, müssen Sie die Software nach jeder Iteration den Benutzern und Benutzerinnen zur Verfügung stellen. Entwickler lernen neue Fakten über die Fachlichkeit, während Fachexperten neues Optimierungspotential entdecken. Damit sind wir bei einem der Kernelemente agiler Softwareentwicklung: Sie entwickeln Software iterativ-inkrementell. Nur unter diesen Bedingungen funktionieren DDD und sein Knowledge Crunching.

Priorisieren

Beziehungen zwischen den agilen Werten und DDD finden sich zudem in anderen Bereichen wieder. So heißt es in den Prinzipien des agilen Manifests, die höchste Priorität sei es, “den Kunden durch frühe und kontinuierliche Auslieferung wertvoller Software zufriedenzustellen.” Typische agile Prozesse entsprechen diesem Prinzip, indem sie Domänenexperten Features priorisieren lassen. So lässt sich das Prinzip umsetzen, ohne die Struktur der Software oder den Code zu beeinflussen.

Domain-driven Design ergänzt dazu das Konzept der Core Domain. Sie bezeichnet den Bereich eines Systems, der die eigentliche Motivation des Projekts implementiert. Damit hebt sie sich zum Beispiel von Generic Subdomains ab, die keine Differenzierung ermöglichen. Bei einer Core Domain kann es sich etwa um einen Produktkonfigurator handeln, mit dessen Hilfe sich das Unternehmen vom Wettbewerb abhebt. Eine Generic Subdomain könnte beispielsweise das Schreiben der Rechnungen sein. Das ist zwar ebenso wichtig, weil es ohne Rechnungen keinen Umsatz gibt, hilft jedoch nicht bei der Differenzierung.

Core Domain und Generic Subdomain brechen den Wert der Software auf die Struktur der Software herunter. Es gibt wertvolle und weniger wertvolle Teile der Software (Abbildung 1). Der Unterscheidung in Core Domain und Generic Subdomain liegt eine einfache Beobachtung zugrunde: Offensichtlich weisen nicht alle Teile eines Softwaresystems dieselbe Qualität auf. Davon ausgehend ergeben sich nur zwei Handlungsoptionen: Entweder Sie überlassen die Qualitätsverteilung dem Zufall, oder Sie lenken sie aktiv. Entscheiden Sie sich fürs Lenken, müssen Sie wissen, welche Teile besonders gut sein sollen. Genau dabei kommt die Core Domain ins Spiel, bei der Sie dementsprechend auf die höchste Qualität achten und so einen Wettbewerbsvorteil erzeugen.

Abbildung 1: Die Core Domain Produktkonfigurator und die Generic Subdomain Rechnungslegung erhalten unterschiedliche Prioritäten.

Genau genommen meint Qualität in diesem Kontext die Wartbarkeit und Anpassungsfähigkeit. Wenn sich ein Unternehmen durch einen Produktkonfigurator vom Wettbewerb differenziert, sollte er sich leicht benutzen und adaptieren lassen. Beim Schreiben der Rechnungen braucht es hingegen andere Qualitäten wie Korrektheit. Zweifellos ist ein Qualitätsproblem bei der Rechnungslegung unangenehm, beim Produktkonfigurator wächst es sich wegen dessen Wichtigkeit zu einem echten Wettbewerbsnachteil aus.

Mit konkreten Patterns wie Core Domains unterstützt DDD dabei, das abstrakte, agile Konzept von “wertvoller” Software auf Ebene der Struktur der Software zu konkretisieren. Dementsprechend lässt sich Software dann als wertvoll bezeichnen, wenn sie in der Core Domain eine hohe Qualität erreicht.

DDD und die Teams

Agile Vorgehensweisen predigen crossfunktionale Teams. In einem solchen Team versammeln sich sämtliche Rollen, um eine geschäftsrelevante Funktionalität umzusetzen. Beispielsweise finden sich im Team Entwickler und Entwicklerinnen mit unterschiedlichen Ausrichtungen wie Frontend oder Backend. Zusätzlich existieren womöglich weitere Rollen wie die von UX-Experten (User Experience) oder Betriebsspezialisten.

Domain-driven Design kommt aus einer anderen Richtung zu einem ähnlichen Ergebnis. Es teilt ein Softwaresystem in Bounded Contexts auf. Dahinter verbergen sich fachliche Module, die eine bestimmte, abgetrennte fachliche Funktionalität integrieren, zum Beispiel die Rechnungslegung oder das Entgegennehmen von Bestellungen. Darüber hinaus besitzen sie eine Bedeutung für die Analyse, denn in einem Bounded Context gilt eine bestimmte fachliche Begrifflichkeit. Zur Rechnungslegung gehören dementsprechend Begriffe wie “Mehrwertsteuer” oder “Inkasso”.

Zunächst scheint es, als definierten Bounded Contexts lediglich die Struktur der Software. Doch der Schein trügt, den DDD lässt ihnen daneben eine Bedeutung für die Organisation des Projekts zukommen. Idealerweise kümmert sich genau ein Team um einen Bounded Context. Da das Team für den spezifischen Bounded Context und damit ebenfalls für die darin implementierte fachliche Funktionalität verantwortlich ist, kann es autonom bestimmte fachliche Änderungen vornehmen.

Dieselbe Idee liegt einem crossfunktionalen Team zugrunde. Dabei bauen Sie ein solches derart auf, dass es fachliche Features möglichst allein implementieren kann. Agilität konzentriert sich dabei auf die Zusammenstellung des Teams, optimalerweise sollte es alle Rollen abbilden. Domain-driven Design dagegen orientiert sich an der Aufteilung der Software, die so erfolgen soll, dass jedes Team eine unabhängige Funktionalität umsetzen kann. Sobald Sie beide Konzepte kombinieren, entstehen crossfunktionale Teams, die an einem Bounded Context arbeiten und eine Fachlichkeit vollständig bearbeiten (Abbildung 2).

Abbildung 2: Ein crossfunktionales Team arbeitet an einem Bounded Context.

Ein solches Team besteht aus fünf bis acht Personen, die gemeinsam Software entwickeln. Oft fallen Systeme jedoch so groß aus, dass ein einzelnes Team die damit verbundene Arbeit nicht mehr bewältigen kann. Deswegen müssen Sie in einem solchen Fall mehrere Teams koordinieren. Dazu sieht DDD Beziehungen vor, die sich aus Bounded Contexts ergeben, die Sie den Teams zugeordnet haben (Abbildung 3).

Abbildung 3: Die beiden Beziehungsarten zwischen Teams in Domain-driven Design – Customer/Supplier und Conformist – folgen unterschiedlichen Regeln.

Wenn ein Team für die Implementierung von Features im eigenen Bounded Contexts Zulieferungen eines anderen Teams benötigt, geht es eine Customer-Supplier-Beziehung ein. Als Kunde fordert es Funktionen beim anderen Team an, das dann die Zuliefererposition einnimmt. Im Kontext unseres Beispiels formuliert, kümmert sich ein Team um die Rechnungslegung und braucht Unterstützung seitens des Teams, das die Bestellungen entgegennimmt. Ohne eine Schnittstelle, die Informationen über die Bestellung liefert, lässt sich kaum eine Rechnung schreiben. Das Customer-Team kommuniziert die notwendigen Features, und beide Teams verhandeln anschließend über die notwendigen Aufgaben und den Zeitplan für die Zulieferung.

Eine Alternative dazu beseht im Conformist. Hierbei kann das Team nichts anfordern, sondern muss sich an das anpassen, was es angeboten bekommt. Das kann zum Beispiel notwendig sein, wenn das andere Team nicht mehr zu wartende Legacy-Software betreut und daher spezifischen Anforderungen schlicht nicht nachkommen kann. Wenn sich die Software für das Entgegennehmen der Bestellungen nicht ändern lässt, findet sich das Team für die Rechnungslegung in einer Conformist-Rolle wieder, mit den entsprechenden Auswirkungen für die Entwicklung der Software.

Genau genommen existieren diese Beziehungen auf Ebene der Bounded Contexts. Das bedeutet, sobald ein anderes Team die Verantwortung für einen Bounded Context übernimmt, hat es ebenso die dazu gehörende Rolle inne, wie Customer oder Conformist.

Erneut ergänzen sich DDD und Agilität: Autonome Teams, die möglichst eigenständig fachliche Anforderungen erfüllen können, erfahren Unterstützung durch die Patterns, weil sie nun Hilfe von anderen Teams anfordern können. Solche Patterns setzten auf eine dezentrale Organisation. Nachdem sie eine Customer/Supplier-Beziehung definiert haben, können die Teams entsprechend dieser Beziehung interagieren. Eine zentrale Koordination, wie sie einige Ansätze zur Skalierung agiler Methoden vorsehen, ist dann nicht notwendig.

Die sogenannte Team-Topologie [5] beschreibt weitere Beziehungen zwischen Teams. Sie erweitert diese Konzepte um Konstrukte wie Plattformteams, die keinen fachlichen Teil des Systems wie einen Bounded Context verantworten, sondern eine Plattform, die technische Features bietet und auf der andere Teams aufbauen können.

Menschen, keine Roboter

Alle diese Patterns und Vorgehensweisen sowohl im Bereich DDD als auch der Agilität wirken sich auf die formale Organisation aus. Dementsprechend fänden sie in einem Organigramm ihren Niederschlag. Aber Menschen richten sich nicht immer nach den Organigrammen. Nur weil irgendwo steht, dass ein Team einem anderen Team helfen soll, bedeutet das noch lange nicht, dass sich die Mitarbeitenden tatsächlich so verhalten. Alle kennen Möglichkeiten, um Reorganisationen oder Anweisungen des Managements zu umgehen.

Hier greift ein wichtiges Konzept aus dem agilen Manifest: Individuen und Interaktionen spielen eine wichtigere Rolle als Prozesse und Werkzeuge. Das lässt sich so interpretieren, dass formale Kollaborationen, wie sie DDD oder Teamtopologien festlegen, nicht so stark ins Gewicht fallen wie die tatsächlichen Interaktionen der Individuen. Die Arbeit vieler agiler Coaches oder Scrum Master konzentriert sich darauf, diese Interaktionen und die zwischenmenschlichen Beziehungen zu verbessern, da beide den Erfolg von agiler Umsetzung kritisch beeinflussen.

Im Bereich DDD hat sich der Begriff “sozio-technische Systeme” etabliert, bei dem Sie neben der Software auch die Organisation betrachten, die das Softwaresystem entwickelt. Die Erfahrung zeigt, dass genau in der Interaktion zwischen Organisation und Software in den Projekten die wesentlichen Probleme begraben liegen. Zudem reagieren Organisationen und Menschen sehr unterschiedlich auf Maßnahmen wie Reorganisationen, während Software im Wesentlichen deterministisch ist und sich mit ingenieursmäßigem Vorgehen umsetzen lässt.

Schein und Sein

Daher kämpfen DDD und Agilität mit einem sehr ähnlichen Problem, nämlich dass die Konzepte nur scheinbar realisiert werden. Dafür gibt es den Begriff Cargo-Kult, der auf die Bewohner von Inseln im Pazifik anspielt. Sie beobachteten im Zweiten Weltkrieg amerikanische Flugzeuge, die Güter zu den Inseln brachten. Allerdings verstanden sie die Hintergründe nicht. Nachdem die Amerikaner die Inseln verlassen hatten und weitere Güter ausblieben, bauten sie sich Landebahnen oder Kopfhörer, um das Verhalten der Amerikaner zu imitieren – in der Hoffnung, ebenfalls Güter zu erhalten.

Im Fall von Cargo-Kult-Agilität können Sie beispielsweise sämtliche Scrum-Meetings abhalten, ohne das agile Manifest und die dort definierten Werte zu befolgen. Dazu gehören unter anderem das Schaffen von Geschäftswert, die enge Kooperation von Fachexperten und Entwicklern oder die Optimierung des Vorgehens. Bei Domain-driven Design können Sie die Techniken nutzen, also ein System in Bounded Contexts zerlegen, ohne die Architektur tatsächlich am Business-Wert auszurichten oder den Geschäftssinn des Systems wirklich zu verstehen und optimal zu unterstützen.

Die Gefahr, DDD oder Agilität in dieser Art umzusetzen, besteht, weil diese vordergründigen Aktivitäten leicht zu überprüfen und im Vergleich zu den agilen Werten einfach zu verwirklichen sind. Tatsächlich an der Ausrichtung des Projekts, der Architektur oder an den Werten zu arbeiten, verlangt viel mehr Aufwand. Darüber hinaus tun Sie sich deutlich schwerer, zu erkennen, ob Sie diese Werte oder Ausrichtung wirklich umgesetzt haben.

Kollaborative Modellierung ist eine praktische Technik aus dem DDD und ein gutes Beispiel für die unterschiedlichen Ebenen. Auf den ersten Blick geht es schlicht darum, ein Artefakt zu erzeugen. Beispielsweise ergibt ein Event Storming einen Überblick über alle Events in einem bestimmten Geschäftskontext. Als ein konkretes, anfassbares Ergebnis steht am Ende ein Artefakt, das eine bestimmte Qualität aufweist.

Gleichzeitig bedeutet Event Storming einen Prozess, bei dem Personen miteinander interagieren. Dabei tritt offen zutage, welche Spannungen oder Allianzen es in der Organisation gibt und welche Menschen in welchen Bereichen über besonders detailliertes Wissen verfügen. Zusätzlich können die Beteiligten im Rahmen eines Event Stormings die gemeinsame Arbeit an einem Problem üben.

Fazit: Nur gemeinsam

Um zu sehen, wie eng die Beziehung zwischen Agilität und DDD ist, lohnt es sich, die Frage zu stellen, ob man DDD ohne Agilität überhaupt realisieren kann. Domain-driven Design erfordert die Ausrichtung des Projekts am Geschäftswert und ein präzises Verständnis dafür, was das Projekt wirklich geschäftlich erzielen will. Das funktioniert jedoch ausschließlich über enge Kollaboration – und die fordert Agilität. Ebenso lässt sich wie schon erwähnt die Anpassung des in der Software implementierten Modells als Basis des DDD-Knowledge-Crunchings nur durch iterative-inkrementelle Entwicklung erzielen. Dementsprechend müssen Sie die grundsätzlichen Eckpunkte von Agilität verwirklichen, um DDD erfolgreich betreiben zu können.

Vielleicht kann man Agilität ohne DDD umsetzen, denken Sie jetzt vermutlich. Schließlich scheint DDD im Kern eher technisch zu sein und sich auf Architektur zu konzentrieren. Tatsächlich lassen kann man hochtechnische Systeme ebenfalls agil entwickeln, beispielsweise eine Maschinensteuerung. In einem solchen Bereich ergibt DDD schwerlich Sinn, da es sich auf Systeme konzentriert, die Geschäftsprozesse unterstützen. Für solche Systeme wird ein agiler Prozess aber vermutlich dazu führen, dass zumindest grundlegende Teile von DDD zum Einsatz kommen.

Domain-driven Design und Agilität sind zwei wesentliche Mechanismen moderner Softwareentwicklung. Im Mittelpunkt von Agilität stehen die Werte aus dem agilen Manifest und ein Vorgehen in Iterationen. Bei DDD geht es darum, die Domäne und die Fachlichkeit besonders gut abzubilden. Damit operiert DDD eher auf Ebene der Entwicklung und Architektur, während Agilität eher ein Vorgehensmodell beschreibt. Doch beide bedingen sich mehr oder weniger gegenseitig, wenn Sie sie tatsächlich effektiv umsetzen wollen. Außerdem stehen letztlich bei beiden Konzepten Menschen im Mittelpunkt – und damit die Frage, wie sie agil und an der Domäne orientiert entwickeln können. In Bereichen wie sozio-technischen Systemen treffen beiden Ansätze zusammen, um dieses zentrale Problem der Softwareentwicklung zu lösen.

Möchten Sie sich weiter mit dem Thema beschäftigen, empfehle ich Ihnen dazu das ein Video eines Überblicksvortrags [6]. Ebenso gibt es zahlreiche Clips rund um Themen im DDD-Umfeld [7] und über die Bedeutung der Organisation für die Softwarearchitektur [8]. (csi)