{ Sebastian Jancke, ein Blog }

• Bisher in dieser Serie:

• DDD – Eine Einführung,

• DDD – Allgegenwärtige / Universelle Sprache

In meinem Artikel “DDD – Eine Einführung” hatte ich versucht einen Überblick über Domain Driven Design und seine Auswirkungen zu geben. Leider fehlte dabei eine genaue Definition. Dies ist allerdings nicht einfach und ich bezweifle, ob es derzeit eine komplette und exakte Definition von DDD gibt. Die Beschreibungen auf Wikipedia scheinen mir unvollständig, da sie zu sehr auf den Aspekt des Objekt-Design abzielen. Auch im Buch selbst wird eher schwammig in das Thema eingeführt: Man bekommt schnell ein Gefühl für DDD und, mit Blick auf das Inhaltsverzeichnis, auch für den Umfang. Trotzdem fehlt eine präzise, umfassende Definition. Daher ist dieser Artikel sicherlich zunächst nur ein Versuch – ich maße mir keine Vollständigkeit an.

Der Grund dafür liegt, meiner Meinung nach, in der Tatsache begründet, dass DDD eigentlich vor allem eines ist: ein philosophischer Ansatz, wie Problemdomänen in Software implementiert werden sollten:

• Das Modell, und damit die Domäne, sind im Herzen unserer Software

Und "drumherum" bildet DDD damit eine Entwurfsmuster-Sprache, die uns ermöglicht darüber zu kommunizieren. Dies würde ich als eine Definition von Domain Driven Design und dessen Kern bezeichnen wollen (siehe auch David Laribee's Artikel dazu).

Worin liegt dies begründet und welche Auswirkungen hat dieser Ansatz für uns? Gehen wir also zurück zum Anfang. Zunächst dreht sich bei der Erstellung von Software alles um Modelle und Abstraktionen. Haben wir eine gegebene Domäne, so bauen wir zu einer Teilmenge daraus ein Modell, eine Abstraktion der Domäne. Die gesamte Domäne (wie eigentlich alles auf der Welt) ist natürlich zu groß, um sie vollständig zu modellieren. Wenn wir Software entwickeln, bauen wir also primär ein Modell einer Domäne.

Derzeit besteht unsere bester Weg zu Modularisierung und Abstraktion in der Nutzung von Objekt Orientierung. Damit liegt die Idee nahe, unser Modelle durch “nakte” Objekte zu implementieren - wie wir es in der Uni gelernt haben bevor wir über Datenbanken, Transaktionen und Infrastruktur nachdachten. Idealer weise gibt es zwischen Quelltext und Modell keine Unterschiede, also keine Übersetzungen. Im Artikel “DDD – Allgegenwärtige / Universelle Sprache” bin ich bereits darauf eingegangen, warum Eric Evans Übersetzungen als kritisch ansieht. Unser Modell ist also von der Domäne gesteuert.

Wenn wir nun ein Modell der Domäne erstellen, ergibt sich direkt die Frage: Wer kennt die Domäne? Die Architekten? Oder Software Analysten? Oder Entwickler? Wohl kaum. Erstere denken wohl eher an Entwicklung im großen Rahmen, letztere im sehr kleinen und Software-Analysten können wohl analysieren, aber kennen wohl nicht jede Problem-Domäne. Diejenigen, die eine Domäne am besten kennen sind aber direkt vor unseren Nasen: Der Kunde und seine Experten. Diese Idee sehen wir auch in anderen Bereichen, zB in den Agilen Prozessen. Im eXtreme Programming heißt das ganze “Customer On Site”. Da das Modell also keine verborgene Magie innerhalb der Software ist, sondern eine – für alle sichtbare – Abstraktion, ergibt sich die Grundlage des Domain Driven Design:

• Das Modell, und damit die Domäne, sind im Herzen unserer Software

Dies hat weitreichende Konsequenzen auf alle Bereiche, wie Anforderungen an die Architektur, Auswirkungen auf Objekt-Design, das Team, seine Prozesse, etc. Weil wir zum Beispiel dieses Modell kommunizieren müssen, sowohl intern als auch extern, liegt die Idee nahe, eine gemeinsame Sprache in allen Beriechen zu nutzen: angefangen bei der Kommunikation, über Dokumentation, Diagrammen bis hin zum Quelltext. Ideal ist es also, wenn sich die Sprache und damit das Modell im Quelltext manifestiert. Dann könnte man nur durch das Lesen des Quelltextes im Domänen-Modul eine Menge über die Domäne selbst lernen.

Zusammenfassend kann man also sagen, dass Domain Driven Design ein Ansatz zur Software-Entwicklung ist, der das Modell einer Problemdomäne ins Zentrum stellt. Kritik und Erweiterungen sind willkommen!

Nachtrag: Definitions-Absatz erweitert um die Idee der Pattern-Language.