Interview mit Matthias Bohlen

Domain-driven Design: Warum jetzt die Zeit für DDD gekommen ist

Hartmut Schlosser

Domain-driven Design erlebt unter Software-Architekten gerade einen großen Zuspruch. Im Interview erklärt Mathias Bohlen, Experte für effektive Produktentwicklung und Trainer des DDD Camp, warum das so ist, was taktisches DDD bedeutet und wie man die ersten Schritte in Richtung Domain-driven Design unternehmen kann.

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?

DDD hilft uns nicht nur beim Softwareschnitt, sondern auch beim Teamschnitt.

Matthias Bohlen: Die Zeit für DDD ist aus vielen Gründen jetzt gekommen. Ich nenne mal nur zwei davon: Die Komplexität der Systementwicklung und das Bedürfnis nach agilen, schlagkräftigen Teams, die nicht ständig aufeinander zu warten brauchen.

Einerseits ist mittlerweile unsere Art, Systeme zu entwickeln, so komplex geworden, dass sich eine falsche fachliche Aufteilung des Systems noch schwerer beheben lässt als früher. Denke z.B. an Microservices, die in Containern ablaufen, die auf geeigneter Infrastruktur orchestriert werden. Den Schnitt dieser Services ändert man halt nicht mehr “mal eben schnell”. DDD kann Teams dabei helfen, Systeme entlang der Bounded Contexts fachlich sinnvoll zu schneiden, so dass dieser Schnitt nicht so oft geändert zu werden braucht. Die Fachlichkeit einer Versicherung (Risiko, Produkt, Vertrag, Prämie, Schaden, Leistung zum Beispiel) ist seit 150 Jahren dieselbe, selbst wenn es angeblich demnächst Peer-to-peer-Versicherungen in der Blockchain geben soll.

Der andere Grund, warum DDD so aktuell wird, sind agile, selbstständige Teams. DDD optimiert die Kommunikation zwischen Domänenexperten und IT-Leuten. Und: DDD hilft uns nicht nur beim Softwareschnitt, sondern auch beim Teamschnitt. Wenn Teams jeweils nur kleine Modelle, also einen geschickt gewählten Ausschnitt der Fachdomäne, bearbeiten, dann brauchen sie nicht ständig auf das Ergebnis des Nachbarteams zu warten, sondern können vorwärts laufen. Würden wir auch noch die Domänenexperten mit in die Cross-funktionalen Teams setzen, dann würde DDD noch viel mehr Spaß machen, als es das heute schon tut.

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

Matthias Bohlen: Besonders reizvoll ist für mich die konsequente Durchgängigkeit der DDD-Methodik, von den ersten Meetings zwischen Domänenexperten und Entwicklern, über das strategische Design, bis hin zum Anwendungscode, der aus den immer gleichen neun DDD-Grundbausteinen zusammengebaut werden kann. Im DDD-Camp, das Anfang Dezember stattfindet, gehen wir in Kleingruppen einmal komplett durch diesen Prozess, bis hin zur lauffähigen Cloud-Anwendung, die wir am Schluss benutzen und feiern können.

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

Matthias Bohlen: Eher methodisch, doch mit Berührung zur Technik. Mit den Domänenexpert/inn/en reden wir über Modell-Elemente wie Services, Aggregates, Entities, Value Objects, usw. Für diese Elemente hat jedes Team intern bereits vorher ein Mapping auf die Technik festgelegt. Da ist also vollkommen klar, wie z.B. ein Aggregate im Prinzip umgesetzt werden wird. Das bedeutet: Wenn du aus einem Fachmeeting kommst, kann das Team die besprochenen Modell-Elemente sofort im Code umsetzen, weil das Mapping auf den Code schon standardisiert ist. Dieses Mapping ist natürlich in jedem Team möglicherweise anders, denn es hängt von Architektur, Plattformen, Programmiersprachen und eingesetzten Frameworks ab. Daher entscheidet jedes Team selbst über dieses Mapping.

Auf dem DDD Camp vermittelst du Grundlagen des „taktischen” DDD. Was ist das?

Matthias Bohlen: Strategisches Design bedeutet, die eher längerfristig gültige Aufteilung des Systems und der Teams zu finden. Taktisches Design findet jeden Tag statt. Jedesmal, wenn ein Feature entworfen und programmiert werden soll, muss Fachlichkeit in Modell-Elemente (z.B. Events, Services, Aggregates, usw.) zerlegt werden, d.h. ich bekomme aus jeder mit den Fachexperten besprochenen User Story ein paar solcher Elemente. Die programmiere ich dann mit dem zuvor verabredeten Mapping, mache sie vorzeigbar und frage die Fachexperten, ob das prinzipiell so stimmt. Wenn ja, programmiere ich alles in hoher Qualität aus. Die „Taktik“ des DDD ist für mich dieser wöchentlich wiederholbare Zyklus aus Kommunikation, Modellierung, Umsetzen und Feedback.

DDD gilt als Methode zum Bauen von Microservices. Richtet sich das Camp also nur an Entwickler & Architekten von Microservices-Lösungen?

Die Ziel-Architektur braucht keine Microservices zu enthalten, um DDD sinnvoll zu machen.

Matthias Bohlen: Nein, die Ziel-Architektur braucht keine Microservices zu enthalten, um DDD sinnvoll zu machen. Es reicht, wenn die Fachlogik der Domäne genügend kompliziert ist. Für fachlich reichhaltige Domänen lohnt sich die Investition, DDD als Methode zu erlernen, sich Fachexperten zu suchen, sie mit Teams eng zusammenarbeiten und gemeinsam die Systeme entwerfen zu lassen. Egal, ob du einen Monolithen, Microservices, Components-and-Connectors oder Pipes-and-Filters als Architekturgrundlage hast: Sobald die Domäne schwierig genug wird und die Zahl der Missverständnisse zwischen Fachexperten und Entwicklern zunimmt, dann setze DDD ein.

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

Matthias Bohlen: Zuerst: Das Ganze steht und fällt mit den Fachexpert/inn/en. Du brauchst kundige Leute, die großes Wissen über die Prozesse und Daten in der Domäne haben. Diese Leute müssen auch Zeit haben und motiviert sein, mitzumachen. Sie sollten abstrahieren und die Domäne gut verständlich erklären können. Wenn ich in die Kalender von Fachexperten in typischen Unternehmen schaue, finde ich vor Ablauf von 6 Wochen manchmal schon gar keinen Termin für DDD-Gespräche. Hast du die Leute einmal gefunden, dann kannst du mit ihnen anfangen zu modellieren, also z.B. mit Hilfe von Event Storming oder Story-Telling ein gemeinsames Domänenverständnis erzeugen.

Auf der langen Wand des Event Stormings findet ihr dann möglicherweise die abgrenzbaren Kontexte, die euch helfen, das Modell auf mehrere Teams aufzuteilen. In einer Context Map könnt ihr das erfassen, näher beschreiben und dann Teams gründen, die dem entsprechen. In jedem Team sprecht ihr dann darüber, wie die wöchentliche Arbeit mit DDD aussehen soll, z.B. indem ihr den Fachgespräche-Rhythmus und das Mapping der neun Standardbausteine auf den Code festlegt. Und dann kann’s losgehen mit dem ersten Aggregate.

Was möchtest du den Teilnehmern des DDD Camp vermitteln? Was ist die Kernbotschaft?

Matthias Bohlen: Ich möchte für die Teilnehmer/inn/en den DDD-Weg von den allerersten Ideen bis zum ausführbaren Code erlebbar machen. In meinen DDD-Schulungen kam öfters das erste “Aha”-Erlebnis: “Matthias, jetzt haben wir ja ein Modell, das wir im Code tatsächlich sofort runterschreiben und ausprobieren könnten. Schade, dass die Schulung jetzt hier zu Ende ist.” Das brachte mich auf die Idee für das DDD Camp. Es fehlte der Schritt ins gemeinsame Tun: gemeinsam eine Cloud App zu bauen, mit Hilfe der Methoden, die uns DDD in die Hand gibt. Genau das gehen wir im Dezember jetzt an. Ich freue mich schon darauf.

Vielen Dank für dieses Interview!

Matthias Bohlen ist Experte für effektive Produktentwicklung. Er hat als Coach, Consultant und Trainer für Entwicklungsorganisationen aus den Branchen Energie, Touristik, Logistik, Automotive, Telekom, Versicherungen und Gesundheitswesen gearbeitet. Matthias Bohlen hilft Führungskräften und Teams, ihre Performance zu verbessern, Ziele zu erreichen und die Zufriedenheit von Kunden und Mitarbeitern gleichermaßen zu erhöhen.

 

Geschrieben von
Hartmut Schlosser
Hartmut Schlosser
Content-Stratege, IT-Redakteur, Storyteller – als Online-Teamlead bei S&S Media ist Hartmut Schlosser immer auf der Suche nach der Geschichte hinter der News. #java #eclipse #devops #machinelearning #seo. Zum Lächeln bringen ihn kreative Aktionen, die den Leser bewegen. @hschlosser
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: