Bedeutet das, neben der Entwicklung auch noch parallel ein Modell pflegen zu müssen? Als zusätzliche Dokumentation sozusagen? Und wie soll dieses Modell überhaupt aussehen? Brauche ich nur ein Domänenmodell, um von den Vorteilen des Domain Driven Design zu profitieren? Und – was ist überhaupt die „Domäne“?
Das Wichtigste zuerst: Das Domänenmodell ist kein Selbstzweck. Es ist die Verbindung zwischen den fachlichen Anforderungen und der Implementierung des Systems. Eine der wichtigsten Aufgaben eines Systems ist es, die Fachlichkeit widerzuspiegeln. Denn wer braucht schon ein schön designtes System, das sich aber von der realen Fachlichkeit, für die es gebaut wird, immer weiter entfernt?
Die Domäne beschreibt die Fachlichkeit mit ihren individuellen Aufgabenstellungen und Prozessen, Abhängigkeiten, Bezeichnungen und komplexen Zusammenhängen. Die Domäne ist zum einen der Auslöser der Entwicklung, sie ist aber auch die größte Konstante über den gesamten Lebenszyklus der Software hinweg. Das Domain Driven Design stellt deshalb die Domäne ins Zentrum und an den Anfang der Software-Entwicklung. Und ja: Das heißt auch, dass sich der Entwickler mit der zunächst unbekannten Domäne beschäftigt und die fachlichen Herausforderungen versteht, bevor er technische Fragestellungen angeht.
Die fachlichen Zusammenhänge zu fassen und als Basis für die Implementierung aufzubereiten, ist Aufgabe des Domänenmodells. Dabei ist es wichtig zu verstehen, dass ein Modell immer nur einen bestimmten Ausschnitt der Wirklichkeit abbildet und auch das nur aus einer bestimmten Perspektive. Das Domänenmodell erhebt also nicht den Anspruch jedes Detail der Fachdomäne zu beschreiben. Es muss aber genau die für die Implementierung wichtigen Artefakte und Prozesse abstrahieren und mit dem Fokus der späteren Umsetzbarkeit abbilden.
Das Domänenmodell ist keine Einbahnstraße von den Anforderungen zur Implementierung. Auch wenn der primäre Nutzen natürlich die Modellierung komplexer Zusammenhänge ist, dient es auch als Resonanzfläche der entwickelten Artefakte. Konkret bedeutet das: Wenn ein Entwickler merkt, dass sich im Modell festgeschriebene Beziehungen und Sachverhalte so nicht im Code abbilden lassen oder ungünstig formuliert sind, wird nicht nur der Code, sondern auch das Modell verändert. Und zwar so, dass Code und Modell zu jeder Zeit synchron bleiben.
Es genügt also nicht, ein Domänenmodell zu erstellen und den Code darauf aufzubauen. Das Domänenmodell lebt mit der Software und umgekehrt. Nur so ist der Mehrwert durch Domain Driven Design auch in Zukunft sichergestellt. Genauso wenig ist das Domänenmodell nur eine neue Dokumentationsart. Es wird nicht nachgezogen, nachdem die Implementierung bereits stattgefunden hat, sondern bestimmt Designentscheidungen und dient als Basis für die gesamte Kommunikation im Team.
Mehr zum Thema Kommunikation gibt es im nächsten Artikel der Serie.