Mit dem zunehmenden Fokus auf Microservices erlebt das Domain Driven Design eine Aufmerksamkeit, die es im Jahr 2004 bei der Veröffentlichung des Buches von Eric Evans Tackling Complexity in the Heart of Software, nicht einmal ansatzweise bekam. Und das Beste: Domain Driven Design ist viel mehr als eine methodische Hilfestellung zur Entwicklung von Microservices.
Stattdessen beschreibt es einen Philosophieansatz zur Softwareentwicklung, der statt technologischen Entscheidungen, die Fachlichkeit ins Zentrum der Implementierung von komplexen Softwareprojekten rückt.
Was soll damit erreicht werden? Zum einen geht es darum, Komplexität an der Stelle einzufangen, an der sie verankert ist. Undurchschaubare Geschäftsprozesse lassen sich nicht besser verstehen und in Software gießen, wenn man das eine oder andere technische Framework verwendet. Stattdessen werden im Domain Driven Design fachliche Sachverhalte bewusst von technologischen Entscheidungen entkoppelt. Technologische Entscheidungen werden so spät wie möglich und möglichst so getroffen, dass sie nicht das Design der Fachlichkeit beeinflussen.
Zum anderen wirkt die Fokussierung auf die Fachlichkeit als Stabilisierungsfaktor für die gesamte Software. Der langlebigste und wichtigste Teil eines Systems ist die fachliche Aufgabenstellung (nicht zu verwechseln mit subjektiv geäußerten fachlichen Anforderungen). Software muss sich auf diese Aufgabenstellung konzentrieren und erst in zweiter Linie technologische Fragestellungen lösen.
Domain Driven Design rückt die Fachlichkeit sowohl beim Designprozess, als auch beim Ergebnis des Designs in den Mittelpunkt.
Zum einen wird eine Methodik bereitgestellt, bei der Fachexperten und Entwicklung gemeinsam die Fachlichkeit designen. Fachlichkeit wird zum Gegenstand enger, beidseitiger Zusammenarbeit. Des Weiteren wird ein Verfahren angeboten, welches die Modularisierung von Software auf Basis der Fachlichkeit stringent ermöglicht.
Komplexität verlangt außerdem nach Organisation und Abstimmung. Domain Driven Design liefert Möglichkeiten zur Aufteilung von umfangreichen Systemen in abgeschlossene Einheiten (Bounded Contexts), die besonders gut in eine Microservice-Architektur passen. Außerdem definiert es Methoden zur Reflektion der Beziehungen und Kommunikation der Teile untereinander.
Trotz aller Euphorie: Domain Driven Design hat (genau wie die Einführung einer Microservice-Architektur) einen Preis und zwar unter Umständen einen höheren Entwicklungsaufwand und insbesondere eine sehr intensive Einarbeitung in fachliche Themen. Ob die Vorteile für Domain Driven Design oder Teile davon überwiegen, muss in jedem Projekt individuell geklärt werden. Die reflektierte Auseinandersetzung mit den mehr oder weniger komplexen Bestandteilen einer Domäne und ihrem Einfluss auf das zu erstellende System schadet aber mit Sicherheit keinem Projekt.
