Gespräch mit dem Autor von "Applying Domain-Driven Design and Patterns"

„Man braucht einen Tag, um von DDD zu profitieren, aber ein ganzes Leben, um es zu meistern“ [Interview mit Jimmy Nilsson]

Hartmut Schlosser

Jimmy Nilsson

In Rahmen unseres Themen-Dossiers zu Domain-driven Design haben wir mit Jimmy Nilsson gesprochen, der der DDD-Bewegung mit seinem Buch „Applying Domain-Driven Design and Patterns“ wichtige Impulse verliehen hat. Was war und ist an DDD so inspirierend? Wie stehen DDD und Microservices zueinander? Welche aktuellen Architektur-Trends sollten wir im Auge behalten?

Inspirationsquelle Domain-driven Design

JAXenter: Hallo Jimmy. Vielen Dank, dass du dir die Zeit für dieses Interview genommen hast!

Jimmy Nilsson: Vielen Dank für die Einladung!

JAXenter: Das Konzept des Domain-driven Design wurde Anfang 2000 geprägt. Du selbst hast mit deinem Buch „Applying Domain-driven Design and patterns“ einen wichtigen Beitrag geleistet. Wenn du dich ein wenig in diese Anfangszeit zurückversetzt: Welche Probleme hatte die Software-Entwicklung vor Domain-driven Design, die dann von der DDD-Bewegung angegangen wurden?

Jimmy Nilsson: Ich denke, damals bestand der erste wichtige Beitrag von DDD darin, eine Reihe nützlicher Werkzeuge bereit zu stellen, um die schwierige Aufgabe zu lösen, wirklich gute, aussagekräftige Domänenmodelle zu erstellen. Genauso wie viele andere habe auch ich jahrelang mit diesem Thema gerungen, und DDD wurde da als eine riesige Inspirationsquelle empfunden.

DDD war für uns eine riesige Inspirationsquelle.

Aber was noch wichtiger, ja sogar viel wichtiger war, waren die philosopischen Aspekte von DDD. Beispielsweise der Fokus auf die  Zusammenarbeit zwischen praktizierenden Software-Entwicklern und Domänenexperten und das ständige Bestreben im Arbeitsalltag, ein gemeinsames Verständnis eines Problems und der gewählten Lösung zu finden. Das ist auch heute noch der Punkt, den ich in den verschiedenen Projekten, in die ich mehr oder weniger tief involviert bin, am häufigsten betone.

JAXenter: Was hat dich persönlich so an DDD gereizt?

Jimmy Nilsson: Nun, da gibt es so viele Dinge. Ich denke, Domain-driven Design und Test-driven Development (TDD) waren für mich die beiden wichtigsten Inspirationen, um ein besserer Entwickler zu werden. Doch wenn ich spontan eine Sache herausgreifen soll… Ich denke,  DDD ist deshalb so anziehend, weil es ein typisches Beispiel für das Sprichwort ist: „Man braucht ein oder zwei Tage, um davon zu profitieren, aber ein ganzes Leben, um es zu meistern.“

Ich gehe davon aus, dass ich von Domain-driven Design noch in meiner gesamten Karriere profitieren werde. DDD ist genau das Gegenteil von „und wieder ein neues Framework“, von Dingen also, die plötzlich auf der Bildfläche erscheinen, um nach einem oder zwei Jahren genauso schnell wieder zu verschwinden.

W-JAX
Mike Wiesner

Data- und Event-driven Microservices mit Apache Kafka

mit Mike Wiesner (MHP – A Porsche Company)

Niko Köbler

Digitization Solutions – a new Breed of Software

with Uwe Friedrichsen (codecentric AG)

Software Architecture Summit 2017
Dr. Carola Lilienthal

The Core of Domain-Driven Design

mit Dr. Carola Lilienthal (Workplace Solutions)

Sascha Möllering

Reaktive Architekturen mit Microservices

mit Sascha Möllering (Amazon Web Services Germany)

Domain-driven Design in der Praxis

JAXenter: Häufig sind den Entwicklern die Prinzipien von DDD grundsätzlich bekannt. Nur ist die Umsetzung alles andere als trivial. Was sind deiner Erfahrung nach die typischen Probleme bei der Anwendung von DDD in echten Projekten?

Jimmy Nilsson: Ein typisches Problem ist, dass DDD in realen Projekten nur als ein Technologie-Stil genutzt wird. So hilft es nicht wirklich viel, ist zugleich für die Entwickler aber anspruchsvoll in der Umsetzung. Das Ergebnis ist eine niedrige Produktivität, ohne wirklich von den Vorteilen zu profitieren.

JAXenter: Hast du einen Tipp für unsere Leser, wie man dieses Problem lösen kann?

Wir sollten uns mehr auf den Aspekt der Zusammenarbeit konzentrieren.

Jimmy Nilsson: Ich schlage vor, sich auf den Aspekt der Zusammenarbeit zu konzentrieren, anstatt verschiedene Modelle zur Problemlösung zu untersuchen. Spiele mit diesen Modellen, probiere sie aus. Und stelle dich darauf ein, dass sie sich ändern werden. Höre nie auf, die Modelle während der Anwendung zu verbessern.

JAXenter: Mit deinem Buch „Applying Domain-driven Design and patterns“ hast du eine Brücke geschlagen zwischen Eric Evans‘ DDD-Konzept und Martin Fowlers „Patterns of Enterprise Architecture“. Denkst du, die Kluft zwischem beidem existiert heute immer noch?

Jimmy Nilsson: Auf jeden Fall. Ich sehe zwar viele Projekte, in denen die Kluft schmaler geworden ist. Aber meistens klafft da noch eine große Lücke auf.

DDD und Microservices

JAXenter: Wenn wir uns die heutigen Diskussionen um Software-Architektur ansehen, dann ist DDD immer noch sehr relevant. Im Kontext der Microservice-Debatte erleben wir vielleicht sogar so etwas wie ein Revival der DDD-Prinzipien. Was denkst du über Microservices?

Jimmy Nilsson: In vielen Situationen beziehe ich mich gerne auf das, was ich den „Bounded-Context-Stil“ von Microservices nenne. Ich habe 2009 einen Artikel geschrieben, der immer noch beschreibt, wie ich Microservices grundsätzlich sehe (obwohl der Teil über Datenspeicherung veraltet ist). Aber „Microservices“ ist definitiv der bessere Namen dafür.

JAXenter: Welcher Aspekt von DDD wird in der heutigen Praxis am meisten vernachlässigt?

Jimmy Nilsson: Nun, auf die Gefahr hin, dass ich mich wiederhole: Ich denke, dass tatsächlich die Idee des Miteinanders und des gemeinsamen Verständnisses einer Sache die Antwort auf diese Frage ist. Ein anderer Aspekt, der mit Microservices zusammenhängt, ist das „strategische Design“ von DDD. Dieser strategische Aspekt ist beispielsweise extrem nützlich, wenn man ein schwieriges, groß angelegtes und undurchsichtiges Projekt übernimmt, da er hilft, Ordnung zu schaffen.

JAXenter: Wo liegen momentan deine Interessen im Bereich Software-Architektur/Methodologie?

Jimmy Nilsson: Aktuell interessiert mich hauptsächlich, Unternehmens-spezifische Sprachen zu entwickeln, die bei der Zusammenarbeit zwischen Domänen-Experten und Software-Entwickler helfen. Diese Sprachen ersetzen normalen C#/Java-Code, der eher ein Hindernis für die Zusammenarbeit darstellt, da es immer eine Art Übersetzungslücke zwischen Technikern und Domänen-Experten gibt. Die Beschreibungen in der Unternehmens-spezifischen Sprache werden dann mit Firmen-spezifischen Engines ausgeführt, die die benötigte Architektur zur Verfügung stellen. Ich finde das enorm spannend, besonders weil die möglichen positiven Effekte so groß sind.

JAXenter: Vielen Dank für dieses Interview!

JimmyNilsson_stvexsJimmy Nilsson ist CEO und Gründer des Unternehmens factor10 und seit über 25 Jahren als Entwickler und System-Architekt tätig. Als Autor des Buches „Applying Domain-Driven Design and Patterns“ hat er der DDD-Bewegung wichtige Impulse verliehen. Jimmy ist Sprecher auf zahlreichen internationalen Konferenzen, darunter OOPSLA, GOTO, JAOO, NDC, Oredev und TechEd.

 

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.