Interview mit dem Vater des Domain-driven Design

„Microservices können Teams dabei helfen, DDD zu praktizieren“ [Interview mit Eric Evans]

Redaktion JAXenter

Eric Evans hat mit seinem Buch „Domain-driven Design: Tackling Complexity in the Heart of Software“ die Methode des Domain-driven Design entscheidend geprägt. Wir haben uns mit ihm über seine Motivation für DDD und den Zusammenhang zwischen Domain-driven Design und Microservices unterhalten.

JAXenter: Hallo Eric. Mit deinem Buch „Domain-driven Design“ hast du 2003 einen IT-Klassiker geschrieben. Was war dabei deine Kernidee? Worum geht es dir beim Konzept des Domain-driven Design?

Eric Evans: Der entscheidende Punkt, um den es mir geht, ist auch der Grund, warum das Konzept „Domain-driven Design“ heißt: Wenn wir Software entwickeln, sollte unser Fokus nicht primär auf den Technologien liegen, die wir verwenden. Stattdessen sollte sich unser Hauptaugenmerk auf die geschäftliche Seite richten, also auf den fachlichen Bereich, den wir mit unserer Software unterstützen wollen – kurz: auf die Domäne. Das ist es, was ich mit Domain-driven Design meinte.

Insbesondere wollen wir das dadurch erreichen, indem wir Modelle dieser Domäne entwickeln und unsere Software diesen Modellen anpassen. Es handelt sich also auch um einen viel stärker konzeptuell ausgerichteten Design-Prozess als gemeinhin üblich.

JAXenter: Domain-driven Design erlebt gerade so etwas wie ein Revival. Insbesondere werden die Prinzipien des DDD immer wieder in den Diskussionen um Microservice-Architekturen genannt. Inwiefern hilft DDD bei Microservices?

Als ich von Microservices hörte, dachte ich, wir sollten diese Idee aufnehmen.

Eric Evans: Anfangs interessierte ich mich für das Thema Microservices, weil ich meinte, Microservices können Teams dabei helfen, DDD zu praktizieren. Mein Ansatz war also genau anders herum.

Doch wie auch immer: Als ich zum ersten Mal von Microservices hörte, dachte ich sofort, dass wir diese Idee aufnehmen sollten. Warum? Nun, eines der größten Probleme beim Modellieren ist, dass man sich immer in einem großen System befindet, in dem viele Leute viele unterschiedliche Dinge tun. Auf konzeptueller Ebene hat man es also mit einer unberechenbaren, unbeständigen Umgebung zu tun. Das Ziel besteht deshalb darin, beständige Konzepte zu finden und ein Modell zu schaffen, das stabile Beziehungen enthält und nicht durch die vielen Dinge, die es integriert muss, in 1000 Stücke zerfällt.

Man stelle sich einmal vor, man würde ein Kartenhaus in der Mitte eines belebten Kinderspielplatzes errichten. Nun, das Haus würde nicht lange stehen bleiben. Die Idee der Microservices ist deshalb, kleine, abgeschottete Bereiche zu schaffen, in denen man tatsächlich Kartenhäuser aufstellen und dafür sorgen könnte, dass diese nicht umstürzen. Nicht alle Modelle müssen so beständig sein, aber manche eben doch.

Lesen Sie auch: Einführung in die Konzepte von Domain-driven Design

Obwohl mich neue Technologien für Service-Interfaces als solche schon interessieren, ist es nicht so sehr der technologische Aspekt, der mich an Microservices reizt. Es geht mir mehr um den Ansatz, Dinge zu isolieren und autonom zu halten, nach dem Motto: Wir brauchen keine übergreifende Datenbank, wir stützen uns nicht auf eine geteilte Codebasis, wir nutzen kein gemeinsames Deployment, unser Team trifft seine eigenen Entscheidungen.

Dieser Ansatz der Isolierung und der Autonomie erlaubt die Art und Weise der Modellierung, die uns auch beim DDD vorschwebt.

JAXenter: Die Metapher des Kartenhauses deutet ja auf eine gewisse Fragilität hin. Nun sieht die Microservice-Idee vor, dass unterschiedliche Teams autonom ihre Software-Einheiten bauen. Läuft man damit nicht Gefahr, dass Teile des Teams und damit der Gesamtarchitektur fragil werden?

Eric Evans: Natürlich ist die Metapher des Kartenhauses ein wenig schief, weil man dabei etwas im Kopf hat, das zu zerbrechlich ist, um zu überleben. Die meisten Modelle müssen nicht so sein – vielleicht kann man sich auch Bauklötze als Metapher vorstellen. Aber auch diese werden nicht stehen bleiben, wenn man sie inmitten eines Kinderspielplatzes aufstapelt, wo alle herumrennen.

Das einzige, was in solchen Umgebungen bestand haben wird, sich Sachen, die flach auf dem Boden liegen oder einfache Dinge, die dafür ausgelegt sind, von einem Ort an den anderen bewegt zu werden. Wenn wir uns daran orientieren, dann ist es kein Wunder, dass die Systeme, die wir designen, so aussehen, wie sie aussehen.

Wenn wir Dinge umsetzen wollen, müssen wir Umgebungen schaffen, in denen diese Dinge auch funktionieren können.

Worauf ich hinauswill: Wir haben es in der Software-Entwicklung mit sehr chaotischen Umgebungen zu tun, in denen wir große Systeme entwickeln sollen, und wir müssen diesen Umstand von vorneherein mit in den Design-Prozess einbeziehen. Wenn wir Dinge umsetzen wollen, die einigermaßen komplex und beständig sein sollen, dann müssen wir Umgebungen schaffen, in denen diese Dinge auch funktionieren können. Das müssen keine großen Umgebung sein – aber sie müssen klare Grenzen aufweisen. Wir nennen das Bounded Context. Nicht alles benötigt ein solches Maß an Schutz, aber manche Dinge schon.

In einem System werden wir dann mehrere solche abgegrenzten Kontexte haben. Und es stimmt, dass nicht alle Teams diese Idee gleich gut umsetzen werden. Doch eine Sache, die ich an der Microservices-Debatte mag, ist, dass die Tatsache mit berücksichtigt wird, dass einige Dinge schief gehen können. Auch auf konzeptueller Design-Ebene kann einiges schief gehen. Und wir möchten ein Gesamtsystem, das robust genug ist, um sagen zu können: Selbst wenn ein gewisses Team einige sehr schlechte Design-Entscheidungen getroffen hat, ruiniert es nicht das Design, das ein anderes Team gewählt hat.

Lesen Sie auch: DDD & Microservices – die JAX-Keynote von Eric Evans

Genau so ein System brauchen wir – andernfalls werden wird ganz einfach nirgends ein gutes Design vorfinden. Denn das ist das Problem bei monolithischen Systemen: Es gibt dort eigentlich nirgends ein gutes Design, weil es nicht diese gerade beschriebene Art von Grenzziehung gibt. Sobald Leute eine schlechte Entscheidung treffen, breiten sich die Konsequenzen dieser Entscheidungen aus – und allmählich hat man einen großen Haufen Matsch vor sich, wie wir es manchmal liebevoll nennen.

JAXenter: Vielen Dank für dieses Interview!

Das Interview wurde von Coman Hamilton auf der JAX 2015 geführt.

Eric EvansEric Evans ist Autor des Buches „Domain-driven Design: Tackling Complexity in the Heart of Software“ und einer der Vordenker für Software Design, Domain-driven Design und Domain Modeling. Eric Evans ist einer der Hauptkontributoren des Portals dddcommunity.org und Sprecher auf internationalen Fachkonferezen.  Auf seinem Blog http://domainlanguage.com/ veröffentlicht er Beiträge zu Domain-Driven Design mit dem Fokus auf strategischem Design.

 

Verwandte Themen:

Geschrieben von
Kommentare

Schreibe einen Kommentar

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