Suche
Experten-Check Teil 1

Domain-driven Design im Experten-Check: Warum ist DDD heute relevanter denn je?

Hartmut Schlosser

(c) Shutterstock / Design Collection

Sieben Experten für Domain-driven Design geben in kurzen Statements Einblicke in ihre Praxiserfahrungen mit DDD. Im ersten Teil geht es darum, was DDD für die heutige Software-Architektur so relevant macht – und welche Projekte sich besonders für Domain-driven Design eignen.

Warum ist Domain-driven Design heute relevanter denn je?

Carola Lilienthal: DDD ist aus zwei Gründen heute so relevant: Einerseits hat DDD mit Bounded Context ein Konzept, um Fachdomänen voneinander abzugrenzen. Für Microservices braucht man genau diese Trennung. Andererseits erkennen immer mehr IT-Leiter, Architekten und Entwickler, dass neue Technologien nicht zu besser nutzbaren und wartbaren Systemen führen, sondern dass Software eine gute fachliche Modellierung braucht. Auch hier bietet DDD viele hilfreiche Antworten. Beides zusammen macht DDD gerade heute sehr relevant.

Stefan Priebsch: Wir bauen heute – gerade im Web-Umfeld – deutlich komplexere Systeme als früher, mit ganz anderen Qualitätszielen. DDD ist ein Ansatz, der für hinreichend komplexe Systeme gut funktionieren kann, von daher gibt es natürlich mit insgesamt steigender Komplexität der Systeme auch mehr „Angriffsfläche“ für Domain-Driven Design. Möglicherweise ist DDD zur Zeit „nur“ ein aktueller Trend, ich denke aber, die Tatsache, dass sich so viele Teams und Firmen in Richtung Domain-Driven orientieren ist auch ein Indikator dafür, dass andere Ansätze möglicherweise weniger gut funktioniert haben.

Die DDD-Experten

Stefan Priebsch_1_0

Stefan Priebsch, Co-Founder der The PHP Consulting Company.

gierke_oliver_0

Oliver Gierke, Leiter des Spring-Data-Projekts bei Pivotal.

Henning Schwentner_wp

Henning Schwentner, Softwarearchitekt und Berater bei der WPS.

Carola Lilienthal_5

Dr. Carola Lilienthal, Seniorsoftwarearchitektin bei der Workplace Solutions GmbH.

ich-small-2679

Michael Plöd, Principal Consultant bei innoQ.

Wolff_eberhard_wp

Eberhard Wolff, Architekt, Berater und Fellow bei innoQ.

Lars Röwekamp

Gründer des IT-Beratungs- und Entwicklungs- unternehmens open knowledge GmbH

Eberhard Wolff: Viele Architekten erkennen durch den aktuellen Trend zu Microservices, wie wichtig der fachliche Schnitt von Systemen ist. Genau dort hilft Domain-driven Design. Interessanterweise hat Eric Evans in seinem Buch „Domain-driven Design“ neben der Architektur auch die Zusammenarbeit zwischen Teams beschrieben. Auch die Wechselwirkung zwischen Organisation und Architektur wird gerade durch Microservices wieder aktuell.

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 Evans 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 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 Microservice-Architektur 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, das Buch wieder aus dem Regal zu holen und sich dem Thema noch einmal intensiver zu widmen.

Henning Schwentner: Domain-driven Design oder allgemeiner Anwendungsorientiere Softwareentwicklung ist immer wichtig gewesen und wird es auch weiter bleiben. Entscheidend ist die Erkenntnis, dass das Wichtige die Fachlichkeit und nicht die Technik ist. Software ist nie Selbstzweck sondern immer nur Mittel zum Zweck. Und dieser Zweck ist es, den Benutzer bei ihrer Arbeit zu unterstützen. Einen neuen Hype erlebt DDD derzeit, weil wir Entwickler durch den Microservices-Architekturstil das Konzept der Bounded Contexts besser verstehen und endlich auch in der Praxis umsetzen können.

Michael Plöd: Einfach beantworten könnte man die Frage mit dem Satz: „Weil gutes fachliches Design immer wichtiger wird und noch nie unwichtig war.“ Aber schaut man unter die Haube, denke ich, dass durch den Trend in Richtung Microservices Abhängigkeiten, die sich im Bauch eines Monolithen versteckten, nun sichtbar werden. Kurzum: Implizite Abhängigkeiten und Strukturen werden plötzlich explizit, was natürlich ein gutes fachliches Design prominent in den Fokus der Aufmerksamkeit rückt.

Lars Röwekamp: In den ersten Jahren wurde DDD lediglich von einer kleinen Gruppe „Interessierter“ adaptiert, die es bereits damals verstanden haben, dass es bei der Entwicklung von Software eher um die korrekte Umsetzung von Fachlichkeit als um technologische Aspekte geht. Ein stets in sich konsistentes Domänen-Modell garantiert, dass es nicht zu unerwarteten Seiteneffekten kommen kann.

Durch die in der Vergangenheit meist strikte Trennung von Fach- und Entwicklungsabteilung war es bis dato nicht ganz trivial für DDD, seine Trümpfe voll auszuspielen. Mit der Einführung von agilen und cross-functional orientierten Teams hat sich die Ausgangssituation vor wenigen Jahren schlagartig geändert. Fachabteilung und Entwicklung rücken mehr und mehr zusammen. Der Entwickler mutiert – im positiven Sinne – vom Technologielöser zum Fachentwickler.

Einen weiteren, wenn nicht sogar den entscheidenden Kick hat DDD durch den Siegeszug der Microservices erhalten. Denn nur, wenn ich es schaffe, Microservices fachlich sinnvoll und möglichst unabhängig voneinander zu schneiden – in DDD spricht man hier von einem „Bounded Context“ –, bekomme ich die gewünschte lose Kopplung mit all seinen Vorteilen. Gelingt mir dies nicht, dann kommt an Ende ein „verteilter Monolith“ heraus, also quasi das Worste Case Scenario der Software-Entwicklung.

 

Lesen Sie auch: Microservices im Experten-Check: Warum eigentlich Microservices?

 

 Bildschirmfoto 2016-08-31 um 11.01.35

 

DDD eignet sich vor allem für Projekte, die…

… eine hinreichend komplexe Fachlichkeit haben. Interessanterweise unterschätzt man meist, wie komplex sich eine Fachlichkeit darstellt, wenn man erst einmal genauer hinsieht. Ich habe das mal in einem Artikel anhand einer Pommesbude aufgezeigt. Stefan Priebsch

… eine reichhaltige Fachlichkeit haben, also mehr als Daten erfassen, speichern und löschen beinhaltet. Carola Lilienthal

… komplexe Geschäftslogik abbilden sollen. Eberhard Wolff

… eine Software entwickeln, die ihren Anwender bei seiner Arbeit unterstützen soll. Henning Schwentner

… anspruchsvolle Fachlickeit umsetzen müssen. Michael Plöd

… fachlich getrieben sind und somit von einem durchgehend in sich konsistenten Domänenmodell stark profitieren. Lars Röwekamp

 
Lesen Sie im Teil 2 des Experten-Checks: Was sind die typischen Probleme bei der Umsetzung von DDD?

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.