Schön wäre es, wenn wir Domain-Driven Design, oder nur kurz DDD in einem einfachen Programmcode wie "Hallo Welt!" darstellen könnten. In der Tat ist es aber weitaus mehr als nur das. Eric Evans hat diese Art der Modellierung stark geprägt und 2003 einen Bestseller herausgebracht: Domain-Driven Design: Tackling Complexity in the Heart of Software. Das Buch steht bei mir auch ganz oben auf der Wunschliste. DDD lässt sich deshalb nicht einfach in zwei Wörtern beschreiben. Dem Bedarf es etwas mehr.
Ich will Versuchen, denjenigen unter euch, die mit dem Thema noch gar nicht, oder noch wenig vertraut sind, das Ganze etwas schmackhaft zu machen. Ich selbst stehe erst am Anfang von DDD und werde nun noch ein Themengebiet mehr in meiner Architekturkiste haben. Neben meinen vielen anderen Themen, die mich täglich begleiten, und mit denen ich stetig wachse, soll DDD einen zentralen Punkt in meiner zukünftigen Softwareentwicklung einnehmen - auf dem Weg zum Architekten.
Das schöne an DDD, und der Art wie Evans es beschreibt, ist die leichte Verständlichkeit und den meiner Meinung nach enormen Gewinn des Wissens, wie wir in unserer Problemdomäne die Software drum herum bauen müssen. Jedes Softwareprodukt bildet im Endeffekt eine Lösung zu einer Problemdomäne. Wichtig ist nun, wie wir das ganze betrachten. DDD dient auch dazu, die Komplexen Vorgänge, die mit zunehmender Größe eines Produktes auftreten besser verstehen zu können. Modellieren wir unsere Diagramm und darauf aufbauend unseren Code gleich richtig, fällt es später leicht, Anpassungen durchzuführen. Dabei beschreibt er schön und auf eine natürliche Art und Weise wie das geht. TDD/BDD und AOP stehen DDD dabei zur Seite und ergänzen die Arbeit damit sinnvoll. Wie und warum das so ist, werden wir späte noch sehen. Lassen wir das für den Anfang erst einmal so stehen.
Was haben wir also davon? Wir bekommen ein Modell an die Hand, mit der uns die Modellierung, die Architektur unserer Software leichter fallen soll. Er betrachtet das aber nicht nur von der Seite der Softwareentwicklung. Vielmehr geht es ihm darum das anfallende Themengebiet einzugrenzen (um es genau zu spezifizieren) und einen einheitlichen Wortschatz zu bilden. Und es dann im Model für die Entwicklung, wie auch im Ganzen für die Entscheider/Managern/Vertriebler usw. als auch dem Benutzer darzustellen.
Er analysiert die Probleme und stellt sie im vereinfachten Modell dar. Ein Vorgehen, das ich zur Erklärung von komplexen Vorgängen aus der Betriebs- und Volkswirtschaft bereits kenne, z.B. der Markt. Und die ersten Gehversuche meinerseits sehen vielversprechend aus. Das schöne daran ist, dass wir bei Evans auf eine mehr als zwei Jahrzehnte gewachsene Erfahrung in der Enterprise-Architektur zurückgreifen können. Im Endeffekt sollten es keine neuen Erkenntnisse sein. Denn Modellierung haben wir davor auch schon betrieben.
In der deutschen Literatur habe ich hier bisher leider nichts Gleichwertiges gefunden. Daher geht es nach dieser kurzen Einführung gleich zum ersten Startpunkten über DDD für Einsteiger in Englisch. Lest selbst nach und entscheidet dann, was für euch sinnvoll ist. Für mich wird es auf jeden Fall ab sofort eine zentrale Rolle in der Softwareentwicklung einnehmen.
An alle die hier ab und zu rein schauen, würde ich mich über weitere Literaturempfehlungen und Erfahrungen freuen.