Suche
Interview mit Oliver Gierke

Grundlegendes Domain-driven Design: Wie Microservices-Architekturen (nicht) von DDD profitieren

Hartmut Schlosser

Oliver Gierke

Domain-driven Design – kurz DDD – erfährt in der aktuellen Diskussion um Softwarearchitektur eine hohe Aufmerksamkeit. Das Anfang der 2000er geprägte Konzept gilt insbesondere als eine der Grundlagen-Theorien für Microservices-Architekturen. Wir haben uns mit W-JAX Speaker Oliver Gierke (Pivotal) über die Herausforderungen unterhalten, die bei der Umsetzung von DDD in die Praxis zu bewältigen sind.

Domain-driven Design und Microservices

JAXenter: Eric Evans hat mit seinem Buch „Domain-driven Design: Tackling Complexity in the Heart of Software“ einen Klassiker geschaffen, der in aktuellen Architektur-Diskussionen immer wieder auftaucht. Nun stammt das Buch aus dem Jahre 2003 – weshalb ist DDD heute wieder so stark im Kommen?

Microservices sind eine sehr direkte Übersetzung des Konzepts aus DDD in die Systemarchitektur.

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 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. Diese Blickwinkel bilden nun die Kontexte, die voneinander isoliert werden sollten, aber dennoch 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 es eben genau dieser Aspekt ist, der Entwickler und Architekten gerade dazu verleitet, Eric Evans‘ Buch wieder aus dem Regal zu holen und sich dem Thema noch einmal intensiver zu widmen.

 

w-jax 2016 logoTreffen Sie Oliver Gierke auf der W-JAX 2016 (7. bis 11. Nov.)

Sessions:

Weitere Infos unter: www.jax.de/programm

.

JAXenter: 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 diese zueinander in Beziehungen? Wie werden sie abgebildet? usw.) als auch in einem Bereich irgendwo zwischen Mikroarchitektur und Design.

Als Entwickler muss man oft mit erheblichem Mehraufwand Unzulänglichkeiten von Technologien ausgleichen.

In letzterem Bereich, in dem vor allem die fundamentalen Bausteine wie Entitäten, Aggregate usw. in den Fokus geraten, gibt es nun große 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 ein 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 Technologien 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.

Domain-driven Design umsetzen

JAXenter: Kannst du einen Praxis-Tipp geben, wie DDD erfolgreich realisiert werden kann?

Oliver Gierke: Hier würde ich vermutlich 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 verwendeten 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.

Im frühen Stadium eines Projektes besteht noch vergleichsweise wenig Wissen über die Domäne.

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 monolithischen System sind Änderungen einfacher zu realisieren als in einem sehr stark verteilten.

In diesem Kontext kann es also durchaus von Vorteil sein, zwei oder drei 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 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.

JAXenter: 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 zeige auf, 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.

JAXenter: Vielen Dank für dieses Interview!

Oliver GierkeOliver 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.
Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Hartmut Schlosser ist Redakteur und Online-Koordinator bei Software & Support Media. Seine Spezialgebiete liegen bei Java-Enterprise-Technologien, JavaFX, Eclipse und DevOps. Vor seiner Tätigkeit bei S & S Media studierte er Musik, Informatik, französische Philologie und Ethnologie.
Kommentare

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.