Blog

DDD Summit 2018
Das große Trainingsevent für Domain-driven Design
9. - 11. Dezember 2019 in Berlin
18
Nov

„Domain-driven Design hilft dabei, Microservices sinnvoll zu schneiden“

Andrej_Thiele

Wie sollte man sich dem Thema DDD am besten annähern? Welche Vorteile kann man aus der Methode ziehen? Und was haben Microservices mit Domain-driven Design zu tun? Andrej Thiele, Senior Consultant bei Conciso und Sprecher auf dem DDD Summit 2019, gibt Antworten.

JAXenter: Hallo Andrej! Was findest du persönlich an Domain-driven Design spannend?

Andrej Thiele: Bei meiner Arbeit als IT-Berater bin ich häufig auf verschiedenste Ansätze gestoßen, die von einem klassischen „Ball of Mud“ über durchdachte mehrschichtige, verteilte Lösungen bis hin zu Microservice-Architekturen reichen. Im Rahmen von agilen Vorgehensweisen hat sich gezeigt, dass ein klarer Kontextbezug der einzelnen Teams nützlich sein kann, und dabei hilft die Verwendung von DDD.

Auch die pragmatische Vorgehensweise bei der Entwicklung von Software wird meines Erachtens gut durch den Domain-driven-Design-Ansatz unterstützt, und daher bin ich letztendlich dort gelandet. In den letzen 10 Jahren habe ich mich auch stark mit den Qualitätsaspekten der Softwareentwicklung auseinandergesetzt. Hier hilft die Modellierung der Fachlichkeit bei der Erstellung von User Stories und Tests im Rahmen von Behaviour Driven Development weiter.

JAXenter: Domain-driven Design liegt im Trend – und das über 15 Jahre nach dem Erscheinen des gleichnamigen Buches von Eric Evans. Warum erlebt DDD gerade jetzt einen Aufschwung?

Durch Domain-driven Designs kann man von den Synergie-Effekten durch die Zusammenarbeit der einzelnen Abteilungen profitieren.

Andrej Thiele: Im Rahmen der Digitalisierung von Unternehmen ist es wichtig, dass Fachlichkeit in einen Softwareansatz umgebaut wird, der für verschiedenste Mitarbeiter verständlich und sinnvoll zu verwenden ist. Durch den Einsatz der Prinzipien des Domain-driven Designs kann man von den Synergie-Effekten durch die Zusammenarbeit der einzelnen Abteilungen profitieren und so den größtmöglichen Nutzen aus dem Wissen eines Unternehmens beim Bau einer Software ziehen.

Gerade in der heutigen Zeit, wo agile Vorgehensmodelle im Trend und Selbstständigkeit und Selbststeuerung von Teams und Teammitgliedern im Fokus liegen, kann DDD dazu verwendet werden, die Kollaboration klarer zu strukturieren und die Fachlichkeit sinnvoll aufzuteilen. Die Verwendbarkeit dieses Ansatzes in diesen Bereichen erklärt meines Erachtens den derzeitigen Aufschwung.

 

JAXenter: Bei DDD arbeiten Domänenexperten und Software-Entwickler eng zusammen. Ist DDD eher ein methodisches Konzept oder ein technologischer Lösungsansatz?

Andrej Thiele: Für mich ist DDD kein technologischer Ansatz, da man sich dabei weder auf eine spezielle Programmiersprache noch auf ein Vorgehensmodell fokussiert. Vielmehr ist es eine Möglichkeit, sich mit komplexen Domänen aus allen möglichen Bereichen des Lebens auseinanderzusetzen und deren Komplexität für alle Projektbeteiligten begreifbar zu machen. DDD ist für mich daher eher eine Art von Kommunikationsansatz, um das geballte Wissen aller Beteiligten in sinnvolle Kontexte aufzuteilen, eine gemeinsame Sprache zu entwickeln und so den größtmöglichen Nutzen für ein Projekt zu erzielen.

DDD und Microservices

JAXenter: DDD gilt als Methode zum Bauen von Microservices. Aber damit ist DDD nicht ausreichend definiert, oder? In welchem Verhältnis stehen DDD und Microservices?

Die Modellierung von Architekturen mit Hilfe von Domain-driven Design hilft, Microservices sinnvoll zu schneiden.

Andrej Thiele: Die Modellierung von Softwarearchitekturen mit Hilfe von Domain-driven Design und die Aufteilung der dort modellierten Fachlichkeit in kleine Verarbeitungseinheiten, die durch klar definierte Schnittstellen miteinander kommunizieren, hilft dabei, Microservices sinnvoll zu schneiden. Diese können dann durch verschiedene, voneinander unabhängig agierende Teams in unterschiedlichen Technologiestacks erstellt und deployed werden. Dadurch ergänzen sich der Modellierungs- und der Technologieansatz gut. Es werden flexible Architekturen geschaffen, die auch in Zukunft noch gut auf neue Anforderungen angepasst werden können.

JAXenter: Wie kann man sich dem Thema DDD am besten nähern? Welche ersten Schritte empfiehlst du?

Andrej Thiele: Um sich diesem Thema zu nähern, würde ich empfehlen, zuerst das oben genannte Buch von Eric Evans zu lesen, um nachzuvollziehen, wo die Wurzeln von DDD liegen und welche Probleme damit überhaupt gelöst werden sollen. Ansonsten hilft es, sich mit gleichgesinnten Menschen auf Meetups oder Konferenzen zu treffen und dort über diesen Ansatz zu sprechen.

Aber wie immer gilt, dass man mit Reden allein nicht weiterkommt, und daher würde ich empfehlen, im Rahmen des Möglichen DDD in Projekten und Produkten auszuprobieren und auch vor Schwierigkeiten nicht zurückzuschrecken. Fehler sind gerade in der Anfangsphase normal, und man sollte sich dadurch nicht davon abhalten lassen, weiterzumachen und die positiven Aspekte für sich zu entdecken. Sollte man mal mit verschiedenen Problemen nicht weiterkommen, gibt es meiner Erfahrung nach in der Community immer die Möglichkeit, Hilfe zu bekommen.

JAXenter: Was möchtest du den Teilnehmern deiner Session vermitteln? Was ist die Kernbotschaft?

Andrej Thiele: Viele Entwickler, Architekten und Domänenexperten sehen in DDD einen Ansatz, der ihnen hilft, ihr Produkt stabiler zu entwickeln, was ich gut und richtig finde. Allerdings passiert es meiner Erfahrung nach häufig, dass dabei das Thema Qualitätssicherung nicht die Bedeutung bekommt, die sie haben sollte. Lisa Crispin und Janet Gregory haben zwar in ihren Büchern über das Agile Testen den Grundstein für das Verständnis von Qualität in der Entwicklung gelegt, aber leider gibt es noch viel
zu viele Entwickler, für die Testen lediglich ein notwendiges Übel ist, was man auch gerne mal eben nebenher machen kann.

Daher versuchen Sven-Torben Janus und ich mit unserem Ansatz, aus Event-Storming-Modellen heraus direkt Testfälle abzuleiten, eine Möglichkeit zu vermitteln, Qualität direkt bei der Domänenerkundung mit zu betrachten und auf diese Weise das drei Amigo-Prinzip auf alle Modellierende zu erweitern. Unsere Kernbotschaft lautet somit, dass Event Storming nicht nur für die Modellierung verwendet werden kann, sondern zusätzlich auch eine große Bereicherung für die Qualitätsicherung das Projektes darstellt.

JAXenter: Vielen Dank für dieses Interview!