Agile, People & Culture
Clouds, Kubernetes & Serverless
Core Java & Languages
DevOps & CI/CD
Microservices
Performance & Security
Serverside Java
Web Development & JavaScript

Warum DDD heute relevanter ist denn je! Interview mit Oliver Gierke

12. Sep 2016

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.

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.

Top Articles About Architecture & Design

Alle News der Java-Welt:

Behind the Tracks

Agile, People & Culture
Teamwork & Methoden

Clouds & Kubernetes
Alles rund um Cloud

Core Java & Languages
Ausblicke & Best Practices

Data & Machine Learning
Speicherung, Processing & mehr

DevOps & CI/CD
Deployment, Docker & mehr

Microservices
Strukturen & Frameworks

Performance & Security
Sichere Webanwendungen

Serverside Java
Spring, JDK & mehr

Software-Architektur
Best Practices

Web & JavaScript
JS & Webtechnologien

Digital Transformation & Innovation
Technologien & Vorgehensweisen

Domain-driven Design
Grundlagen und Ausblick

Spring Ecosystem
Wissen in Spring-Technologien

Web-APIs
API-Technologie, Design und Management

ALLE NEWS ZUR JAX!