Das Konzept des Domain-driven Design (ddd) wurde schon 2003 geprägt. Warum ist DDD heute relevanter denn je?
Oliver Gierke: Das ist eine wirklich gute Frage. Das Buch hat sich ja nicht plötzlich geändert. Ich glaube, dass das Revival hauptsächlich damit zu tun hat, dass es seit einer gewissen Weile verbesserte technische Möglichkeiten gibt, bestimmte Konzepte des Buches umzusetzen.
Die fundamentalen Bausteine von DDD wie Entitäten, Aggregate, Repositories usw. sind ja eigentlich in jeder Architekturform umsetzbar. Nun ist es allerdings so, dass es unterschiedliche Grade gibt, in denen eine bestimmte Architektur zu allgemeineren Konzepten wie DDD passt, und umgekehrt wie gut diese Konzepte eben zu den Konzepten der gewählten Architektur passen.
Zentraler Anknüpfungspunkt zur aktuellen Diskussion um Microservices sind hierbei DDDs Bounded Contexts, die einen Raum kohärenter Begrifflichkeit innerhalb eines Systems beschreiben. Laut Eric ist das zuallererst erst auf die Domänensprache bezogen: eine “Bestellung” meint etwas völlig verschiedenes, je nachdem ob ich aus dem Blickwinkel “Versand” darauf schaue — dann sind Empfangsadresse und Verpackungsmaße interessant —, aus dem Blickwinkel “Rechnungsstellung” — dann interessieren mich Bestellpositionen und deren Steuersätze —, oder aus Lagerhaltungssicht — hier interessieren Bestellpositionen und insbesondere deren Anzahl. Dies Blickwinkel bilden nun diese Kontexte, die voneinander isoliert werden sollten, trotzdem miteinander in Beziehung zu setzen sind.
Die Kernfrage, die sich nun stellt, ist, wie genau man das technisch umsetzt. Wobei ich hier noch gar nicht die Modellierung von Entitäten oder ähnliches meine, sondern das technische Mittel, wie sich diese Kontexte in der Systemarchitektur abbilden. In einem eher monolithischen System finden sich hier auch Mittel und Wege, das zu tun und ich habe auch viele Systeme gesehen die das mehr oder weniger erfolgreich umgesetzt haben.
Den neuen Aspekt, den eine Microservicearchitektur nun in die Diskussion einbringt, ist die Idee, Systemgrenzen an den Grenzen eines Bounded Context zu ziehen, d.h. eine sehr direkte Übersetzung des Konzepts aus DDD in die Systemarchitektur zu wählen. Diese Idee hat sehr weitreichende technische und organisatorische Effekte, die zur Zeit ja sehr umfänglich diskutiert werden. Ich denke jedoch, dass eben genau dieser Aspekt ist, der Entwickler und Architekten gerade dazu verleitet, das Buch wieder aus dem Regal zu holen und sich dem Thema noch einmal intensiver zu widmen.
Die Prinzipien für DDD sind meist grundsätzlich bekannt – allein die Umsetzung in der Praxis ist alles andere als trivial. Auf welche typischen Probleme bist du in Projekten bei der Umsetzung von DDD gestoßen?
Oliver Gierke: Wie gerade beschrieben ist DDD ein weites Feld und betrifft sehr viele Aspekte des Softwareentwicklungsprozesses. Auf technischer Ebene sowohl im Bereich Makroarchitektur — welche Kontexte gibt es? Wie stehen die zueinander in Beziehungen? Wie werden diese abgebildet? usw. — als auch in einem Bereich irgendwo zwischen Mikroarchitektur und Design.
In letzterem Bereich, in dem vor allem die fundamentalen Bausteine wie Entitäten, Aggregate usw. in den Fokus geraten, gibt es nun erhebliche Berührungspunkte mit Frameworks aller Art. Hier ist es leider oft so, dass diese bestimmte Designvorgaben machen, die eine Umsetzung der DDD Konzepte erschweren. Der Klassiker hierbei ist, dass JPA als ORM Technologie, Defaultkonstruktoren voraussetzt und sehr stark auf Mutabilität setzt, so dass es nur mit erheblichem Aufwand möglich ist, wirklich Businessregeln in Entitäten umzusetzen. Java als Sprache erfordert sehr viel Aufwand für die Implementierung von Value Objects. Hinzu kommt, dass es viel Technologie gibt, die einfach schlicht falsche Anreize setzt und vorlebt, `@Email String email` wäre adäquater Ersatz für einen dezidierten Typ `EmailAddress`.
Mein Punkt ist, dass man als Entwickler auf der Umsetzungsebene oft mit erheblichem Mehraufwand Unzulänglichkeiten von Technologie ausgleichen muss, was oft dazu führt, dass man Konzepte und Ideen aus DDD nur halb umsetzt und damit einen großen Teil des Mehrwertes verschenkt.
Kannst du einen Praxis-Tipp geben, wie DDD erfolgreich realisiert werden kann?
Oliver Gierke: Hier würde ich vmtl. analog zur Aufteilung des Buches in zwei große Bereiche unterscheiden: den makro-architektonischen in Bezug auf die Kontextaufteilung und den eher mikro-architektonischen in Bezug auf die Umsetzung und verwendete Technologien.
In ersterem plädiere ich üblicherweise dazu, nicht mit Überaufteilung zu beginnen. Zum einen gibt es bei wenig Erfahrung mit großen Systemlandschaften vielerlei neue Herausforderung wie z.B. das Monitoring dieser Landschaft, die erst einmal gelöst werden wollen. Hier ist man dann oft mit eher technischen Aspekten beschäftigt — etwas, was Entwicklern üblicherweise großen Spaß bereitet, wobei man dann darauf achten muss, sich nicht darin zu verlieren. Sonst baut man schlussendlich eher Framework als Fachlichkeit.
Der eigentlich viel zentralere Punkt ist meiner Meinung nach jedoch der Fakt, dass gerade im frühen Stadium eines Projektes noch vergleichsweise wenig Wissen über die Domäne besteht. D.h. man lernt zu diesem Zeitpunkt besonders viel über sie und es ergibt sich üblicherweise regelmäßiger, recht umfangreicher Änderungsbedarf. In einem eher monolithischeren System sind Änderungen einfacher zu realisieren, als einem sehr stark verteilten. In diesem Kontext kann es also durchaus von Vorteil sein, 2 oder 3 Kontexte, über deren Grenzen und Ausgestaltung man sich noch nicht ganz im Klaren ist, in einem System zu halten bis man eine gewisse Reife erreicht. Wenn dieses System dann sauber strukturiert ist, lässt es sich auch in einem späteren Schritt noch gut separieren, sollte es notwendig werden, das zu tun.
Auf der anderen Seite ist es jedoch auch schwierig, mit nur einem System zu starten. Vor allem, da man damit die Kosten die eine Aufteilung in später mit sich bringt auf einen späteren Projektzeitpunkt verschiebt. Einem Zeitpunkt, an dem man sich eigentlich nicht mehr grundsätzlich überlegen will, wie Systeme jetzt plötzlich miteinander kommunizieren sollen, wie man die Systemlandschaft überwacht usw.
Auf der W-JAX stellst du DDD im Kontext von Microservice-Architekturen vor. Welche Aspekte von DDD besprichst du darin genau?
Oliver Gierke: Mir geht es in meinem Vortrag “Grundlegendes Domain-Driven Design” um den Bereich, der Entwickler in der Umsetzung am stärksten berührt, die sogenannten Building Blocks von DDD: Value Objects, Entitäten, Aggregate und Repositories. Besonders Aggregate werden beim Überfliegen der entsprechenden Kapitel im Buch gern übersehen. Dabei sind sie in Bezug auf Modularität in Systemen und Transaktionsgrenzen der wohl wichtigste Baustein.
Ich gebe also einen Überblick über Herausforderungen dieser Bausteine — z.B. Dinge, die ich oben angedeutet habe — und welche Rolle sie im Kontext der Aufteilung eines Softwaresystems spielen. Wir starten dabei mit der Abbildung in monolithische Systeme um die Teilnehmer abzuholen und identifizieren dann die wichtigsten Punkte hieraus, um auf eine Microservicearchitektur vorzubereiten, sowohl im Migrationsszenario als auch beim Neubau.
Über Oliver Gierke:
Oliver Gierke ist Leiter des Spring-Data-Projekts bei Pivotal, früher besser bekannt als SpringSource. Seit über acht Jahren widmet er sich dem Entwickeln von Java-Enterprise-Applikationen, Open-Source-Projekten und ist Mitglied der JPA Expert Group. Seine Arbeitsschwerpunkte liegen im Bereich Softwarearchitektur, Spring, REST und Persistenztechnologien. Er ist regelmäßiger Sprecher auf deutschen und internationalen Konferenzen sowie Autor von Fachartikeln und des ersten Spring-Data-Buchs.
