Interview mit Marco Heimeshoff

Domain-driven Design im Fokus: „Ein Bounded Context ist kein Microservice!“
Keine Kommentare

Domain-driven Design nimmt im Diskurs der Software-Architektur mittlerweile eine tragende Rolle ein. Das war nicht immer so. Wir haben uns mit Marco Heimeshoff, DDD-Experte und Sprecher auf der W-JAX 2019, darüber unterhalten, was DDD ausmacht, weshalb es im Trend liegt und wie man sich dem Thema in der Praxis annähern kann.

Domain-driven Design im Trend

Entwickler: 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?
Marco Heimeshoff: Die Frage sollte eher lauten, warum hat DDD seinen Aufschwung nicht viel eher erlebt, und aus meiner Perspektive gibt es dafür mindestens drei Gründe.

1. Das Buch von Eric Evans ist voller umfassender Erfahrungen und strategischer Methoden, aber leider in der falschen Reihenfolge geschrieben. Eric sagte 2010 auf der DDDx in London selbst, dass er die letzten Kapitel über strategisches Domain-driven Design an den Anfang hätte setzen sollen, oder gleich zwei Bücher für strategische und taktische Muster zu veröffentlichen.

Der zu starke Fokus vieler Entwickler auf den taktischen Part der ersten 8 Kapitel verhindert nach wie vor, dass DDD als unternehmensweite Philosophie auf allen Hierarchieebenen getragen und gelebt wird.

Das Buch von Eric Evans ist leider in der falschen Reihenfolge geschrieben.

2. Um 2008 herum entwickelten Greg Young und Udi Dahan unabhängig voneinander das Architekturmuster CQRS mit Event Sourcing. Beide Muster, vor allem in Kombination, sind eine ideale Architektur für Domain-driven Design. Sie ermöglichen eine semantische Implementierung von Prozessen und reflektieren deren temporale Natur weitaus besser als die klassischen strukturellen Implementierungen.

Durch die stete Verbreitung dieser Architektur ist auch DDD in den letzten 10 Jahren immer mehr in die öffentliche Wahrnehmung getreten. Dazu kommt noch der parallele Aufstieg funktionaler und funktional reaktiver Paradigmen in den letzten Jahren, der sowohl einen Fokus auf Semantik fördert, als auch die Umsetzung von CQRS und Event Sourcing (und in Folge auch wieder DDD) wesentlich attraktiver macht.

3. Die Microservice-Community löst in vielen Fällen ähnliche Kopplungsprobleme und bedient sich der strategischen DDD-Methoden. Auch wenn die semantischen Einheiten von Bounded Contexts nicht mit den Deployment-Einheiten von Microservices gleichzusetzen sind, profitieren beide Communities viel voneinander.

Entwickler: Was ist für dich der Hauptgrund, sich mit DDD zu beschäftigen?

Marco Heimeshoff: Es gibt für mich zwei wichtige Gründe, einen fachlichen und einen kulturellen.

1. Bei Softwareentwicklung geht es nicht um Software, sondern darum, Probleme zu lösen, und bevor man ein Problem lösen kann, muss man es erst verstehen. DDD bietet dafür diverse Methoden und, noch wichtiger, Heuristiken, um seine eigenen Methoden weiter zu entwickeln. Wer sein Unternehmen nach DDD ausrichtet, sucht den direkten Dialog zwischen Fachleuten und Entwicklern, experimentiert mit Modellierungsmethoden für Problem und Lösungsraum, entwirft Architekturen, die auf die Bedürfnisse der Fachlichkeit zugeschitten sind und fördert Code, der die Fachlichkeit leicht lesbar und sauber entkoppelt implementiert.

Ich beschäftige mich mit Domain-driven Design, weil ich nicht länger Technik zum Selbstzweck bauen, sondern die echte fachliche Komplexität bändigen möchte. Nur durch kollaboratives Erforschen der Domäne mit allen Stakeholdern können wir ein Modell aufbauen und pflegen, das einen ernsthaften Unterschied macht, und DDD nimmt alle Methoden auf, die diesem Zweck dienen.

2. Ich möchte in einer Firma arbeiten, deren Kultur zweckgetrieben ist und die die Bedürfnisse aller Teilnehmer ernst nimmt. Nach Daniel Pink sind, nach gesicherter Grundversorgung, die stärksten Motivatoren in unserer Industrie Autonomy, Mastery und Purpose (oder zu deutsch: Autonomie, Kompetenzsteigerung und Grund/Zweck). Domain-driven Design bietet mit seinen Bounded Contexts (BC) einen Team-Schnitt, in dem jedes Team ein höchstmaß an Autonomie ausleben kann, da es für die
Fachlichkeit und die Architektur innerhalb seines Bounded Contexts selbst verantwortlich ist.

Unabhängig von der Persönlichkeit und den Fähigkeiten wird jede Mastery in DDD gebraucht. Ganz gleich, ob man motiviert ist, die Fachlichkeit zu durchsteigen und ein Domänenexperte zu werden, ein Meister der Architekturmuster und ihrer Tradeoffs, oder der beste Coder/Lehrer/Mob-programmer/Moderator – jedwede Mastery wird gefördert.

Und der Purpose, also die Motivation durch einen tieferliegenden Zweck, die sonst häufig fehlt, ist bei DDD eingebaute Grundvoraussetzung. Bei DDD geht es immer darum, Fachleuten (im DDD-Jargon
„Domänenexperten“ genannt) zu helfen, ihr Business zu erforschen und zu optimieren.

DDD und Mircoservices

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

DDD ist eine Art zu denken und zu arbeiten, bei der die Bedürfnisse der Kunden an oberster Stelle stehen.

Marco Heimeshoff: DDD ist ein philosophisches Konzept. Es ist eine Art zu denken und zu arbeiten, bei der die Bedürfnisse der Kunden an oberster Stelle stehen und der Fokus der Entwicklung auf der Fachsprache und den soziotechnischen Strukturen der Fachlichkeit liegt. DDD ist eine offene Sammlung an Methoden, die diesem Ziel dienen, und wird jedes Jahr durch eine weltweite Community erweitert und geschärft.

Als kleiner, unvollständiger Überblick hier ein paar Methoden aus dem strategischen und taktischen DDD:

Strategisch: Komplexitätsanalyse mit Dynamiken nach Cynefin (Dave Snowden), Exploration mit Wardley Mapping (Simon Wardley), Domänenmodellierung mit Whirlpool (Eric Evans) oder Event Storming (Alberto Brandolini), Strategische Entkopplung durch Bounded Context Mapping (Eric Evans), Soziotechnische Analyse (Melvin Conway / Nick Tune), Antifragile System (Nassim Taleb), System thinking (Donella Meadows)…

Architekturen: Prozessorientierte Architektur (CQRS/ES von Greg Yound & Udi Dahan), Semantische temporale Entkopplung durch funktional reaktive Architektur, Semantische Entkopplung des Frontends durch MVU-Architektur (Evans Czaplicki) …

Code: Semantische Implementierung durch Projektionen, Streams, Actors, Commands & Events, Value Types, Aggregate, Algebraische Datentypen…

Entwickler: DDD gilt als Methode zum Bauen von Microservices. Stimmt das?

Marco Heimeshoff: Diese Annahme ist nicht korrekt. Ein Bounded Context aus dem DDD ist eine fachliche Sprachgrenze, innerhalb derer jeder Begriff eine klare Definition hat, und dessen Form und Größe bestimmt wird durch Teamstruktur, strategische Planung, Modellkomplexität und Legacy-Einflüssen. Ein Microservice ist eine Deploymentgrenze.

Auch wenn ein Bounded Context ggf. in einem Microservice deployt werden kann, sollte man das Mögliche nicht zum Nötigen machen, da beide aus verschiedenen Gründen verändert würden in der Zukunft.
Um Schaden zu vermeiden, liegt mir diese Botschaft sehr am Herzen: Ein Bounded Context ist kein Microservice!

Domain-driven Design in der Praxis

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

Marco Heimeshoff: Wer die Gelegenheit hat, ein Event Storming mitzumachen, sollte das auf jeden Fall als ersten Schritt tun. Diese Methode vereint den Fokus auf Sprache, Kollaboration, Exploration, agile Prinzipien und Implementierungsnähe, ohne dass man dafür einen initialen Lernaufwand betreiben müsste. Ich kenne keinen besseren Einstieg in das Thema.

Für eine Implementierung nach Domain-driven Design empfehle ich dieses Demoprojekt: Modular monolith with DDD. Der Autor führt durch alle Entscheidungen vom Modell über Architektur zur Implementierung und hat alles ausgiebig gut dokumentiert.

Und nach den ersten Schritten kann man in den DDD-Meetups verschiedener Städte und der KDDDConf immer im Oktober in Berlin mit der Community gemeinsam weiter lernen.

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

Marco Heimeshoff: Lösungsentwürfe nach Domain-driven Design sind historisch bedingt häufig fokussiert auf serverseitige Businesslogik und vernachlässigen die UI/UX. Ich zeige auf, dass die Designsprache gleichwertiger Teil der „ubiquitären“ Sprache ist, und dass die UX und dazu passende
Architekturmuster ebenso mit DDD entworfen werden können und müssen.

User Journeys und Subdomänen werden in den dazu passenden Bounded Contexts behandelt und Frontend und Backend wachsen durch kompatible Architekturen semantisch enger zusammen, während sie technisch entkoppelt bleiben.

Entwickler: Vielen Dank für dieses Interview!

Marco Heimeshoff ist Trainer, Coach und Software Entwickler aus Deutschland. Marco liebt Domain-Driven Design und dreht gerne jeden Stein um, wenn man ihm Gehör und Sticky Notes leiht. Er ist fest davon überzeugt, dass lebenslanges Lernen, Fokus auf sprachliche Facetten und Empathie wichtige Grundlagen für qualitativ hochwertige Softwareentwicklung sind. Die Frustration über die ewig alten Methoden führten Marco zu DDD, agiler Software Entwicklung, funktionaler Entwicklung und CQRS mit Event Sourcing. Mit zehn Jahren Erfahrung in diesen Bereichen hilft er Teams bei Veränderungen und beim Lernen vom Code bis hin zur Kultur.
Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -