Aus dem Blickwinkel der Entwicklung ist Software das lauffähige Programm, aus dem Blickwinkel z.B. der Fachexperten ist die Software ein Spiegel ihrer Sicht auf die Fachlichkeit. Erst wenn alle Beteiligten am Softwareentwicklungsprozess ihre Sicht der Software und dem Softwareentwicklungsprozess wiederfinden, ist dieser Prozess stabil.
Als Konsequenz dieser Erkenntnis (siehe Blog 1) rückt DDD ganz bewusst und konsequent die Fachlichkeit in den Mittelpunkt des Softwaredesigns. Software richtet sich nach fachlichen Gegebenheiten aus.
Im Mittelpunkt steht das Domänenmodell, welches in unterschiedlichen Phasen des Entwicklungsprozesses entsteht und schrittweise verfeinert wird.
Zentrale Domänenmodelle neigen dazu, die Verbindung zum Code zu verlieren, durch den sie letztlich umgesetzt werden. DDD hat die Gefahr erkannt, die sich ergibt, wenn diese beiden “Wahrheiten” auseinanderdriften. Das Ziel von DDD ist daher, die Verbindung eines Modells der Domäne einerseits sowie dem Design und Code andererseits in allen Phasen des Software-Entwicklungsprozess konsistent zu halten.
Methodisch betont DDD stark die enge Zusammenarbeit zwischen Experten und Entwicklung, um die Konsistenz zwischen Modell und Code auch tatsächlich gewährleisten zu können.
Strategisches Design im Problemraum
Im strategischen Design werden die strukturellen Entscheidungen des Systems getroffen. Im ersten Schritt wird der Problemraum analysiert. Der Problemraum beschreibt die Gesamtheit der Anforderungen.
Um diese Anforderungen zu strukturieren, wird im strategischen Design (siehe Blog 2) der Problemraum in Subdomänen partitioniert (Destillation). Es entstehen getrennte Subdomänen, welche eine gemeinsame Sicht von Experten und Entwicklung auf das Gesamtsystem widerspiegelt.
Dieser Schritt ist sehr wichtig, bestimmt er doch die Struktur des entstehenden Systems (siehe Abbildung 2).
Ein weiteres wichtiges Resultat dieser Designphase ist die ubiquitäre Sprache (Blog 3).
Mit dieser ubiquitären Sprache existiert eine für Experten und Entwicklung gemeinsame Sprache, welche in alle Phasen und Artefakten zum Tragen kommt.
Strategisches Design im Lösungsraum
Ist das Domänenmodell stabil, so wird auf dessen Basis der Problemraum in den Lösungsraum überführt. Diese Überführung lässt Bounded Contexts und die Bewertung der Zusammenarbeit dieser Bounded Contexts (Collaboration Pattern, Context Map) entstehen (siehe Abbildung 3).
Ein Bounded Context korrespondiert zu Subdomänen. Allerdings gilt leider nicht die einfache Formel, dass ein Bounded Context genau einer Subdomäne entspricht. Eine gute Beschreibung der Probleme, die bei der Überführung von Domänen/Subdomänen in Bounded Contexts zu bewältigen sind, findet sich in [Esposito & al].
Mit den Bounded Contexts liegt eine Grundlage für die Gesamtstruktur eines Softwaresystems vor. Diese Struktur ist durch fachliche Aspekte bestimmt. Die Struktur der Software ist daher in allen Phasen und von allen Beteiligten des Softwareentwicklungsprozesses nachzuvollziehen und wiederzuerkennen.
Taktisches Design
Für ausgewählte Bounded Contexts wird ein explizites und detailliertes Softwaredesign durchgeführt (siehe Blog 5). Das Modell basiert auf Code, ist aber frei von technologischen Aspekten. Dieses Modell ist Basis und Diskussionsgrundlage der Zusammenarbeit zwischen Experten und Entwicklung. Diese steht auch in dieser Phase im Mittelpunkt.
Auswirkung
Methodischer Mittelpunkt des DDDs ist die Zusammenarbeit zwischen Entwicklung und Fachexperten. In allen Phasen des DDDs wird Wert auf kollaboratives und evolutionäres Arbeiten gelegt, also schrittweise Verfeinerung mit gegenseitiger Unterstützung. Alle Ergebnisse des DDD (Subdomänen, Bounded Contexts, taktisches Design) gehören zur gemeinsamen Sicht von Fachexperten und Entwicklung auf die Fachlichkeit und werden gemeinsam entwickelt und fortgeschrieben.
Der Einsatz von DDD bedingt daher nicht nur neue Designkonzepte wie Bounded Contexts, sondern auch eventuell die Anpassung der Arbeitsweisen. DDD unterstützt agiles Vorgehen und integriert sich gut in agile Prozesse wie Scrum (siehe [Vernon2], Kap. 7). Während sich das taktische Design in Sprints integrieren lässt, ist strategisches Design im allgemeinen (je nach Projekt-/Domänengröße) eine projektübergreifende Querschnittsaufgabe. Daher kann sie im Kontext von agilen Methoden mit der Aufgabe der Architektur verglichen werden (siehe [Schneider]):
Des Weiteren sind Bounded Contexts prädestiniert, um Teamstrukturen abzubilden (Context Map). Im DDD stellen sich Teams gemäß eines Bounded Context auf, nicht gemäß der Organisationsstrukturen. Auch aus diesem Grund fügt sich DDD gut in agile Prozesse.
Wie geht es los?
DDD kann ein wichtiger Teil des Entwicklungsprozesses sein. Allerdings ist DDD nicht für jedes Projekt oder System geeignet. Der Aufwand, den DDD mit sich bringt, muss gerechtfertigt sein (siehe [Millett, Kap. 9-10]).
Wie für alle komplexen Methoden ist auch für DDD eine schrittweise Einführung sinnvoll. Der einzuschlagende Weg hängt von einigen Rahmenbedingungen ab:
- Wie weit ist die agile Vorgehensweise bereits etabliert?
- Und ist die Zusammenarbeit zwischen Experten und Entwicklung bereits agil?
Im Mittelpunkt der Einführung sollten die Prinzipien und Grundhaltungen von DDD stehen, insbesondere die intensive Zusammenarbeit zwischen Experten und Entwicklung. Beide Seiten müssen sich aufeinander zubewegen und werden liebgewonnene Arbeitsweisen und Haltungen ändern müssen.
In [Millett, Kap. 9-10] sind einige der wichtigsten Hürden bei der Einführung beschrieben und Kriterien benannt, unter welchen Bedingungen DDD sinnvoll erscheint.
Es lohnt sich auf jeden Fall, sich mit DDD zu beschäftigen. Stellt DDD doch Konzepte und Methoden bereit, um im weiten Niemandsland zwischen Fachlichkeit und Software einen nachvollziehbaren Weg zu bahnen und damit die Stabilität des Softwaresystems zu verbessern.
