Kaum ein Architektur-Ansatz ist so wichtig wie Domain-driven Design (DDD). Insbesondere die Aufteilung eines Systems in mehrere möglichst unabhängige Komponenten oder Bounded Contexts ist nicht nur für Microservices sehr wichtig, sondern kann bei praktisch allen Projekten zu besseren Architekturen führen. Zu oft sehe ich ein System mit hochkomplexen Datenbank-Schemata oder Objektmodellen, die praktisch nicht mehr geändert werden können und besser in mehrere kleinere aufgeteilt werden sollten. Meiner Meinung nach sollte sich deswegen jeder mit diesem Ansatz auseinandersetzen.
Bleibt die Frage, wie man das Wissen zu DDD am besten vermittelt. Sicher kann man ein Buch lesen oder ein klassisches Folien-Training anbieten. Gerade Software-Architektur ist eigentlich ein trockenes Thema: Es geht um Konzepte, Diagramme und abstrakte Entscheidungen. Das übliche Trainingsformat setzt daher auf Folien, um die Konzepte zu erklären. Ab und zu unterbrechen Übungen den Vortrag. Anders sind diese Inhalte anscheinend nicht zu transportieren. Wenn die Teilnehmer*innen später dann die Konzepte wirklich selber nutzen wollen, tauchen oft noch viele Fragen auf. Oder schlimmer noch: Die Konzepte werden falsch umgesetzt, und es fällt niemandem auf. Es ist eben doch etwas anderes, einem Vortrag zuzuhören oder etwas selber umzusetzen.
Architektur-Katas
Daher ist ein Architektur-Kata radikal anders. Es orientiert sich an den Katas aus dem Kampfsport. Dabei wird eine bestimmte Abfolge von Bewegungen ausgeführt, um so einen Ausschnitt aus einem Kampf zu simulieren. Katas in der Programmierung gibt es schon länger. Für Architekturen gibt es Architektur-Katas, die in der ursprünglichen Form allerdings nur zum Ziel hatten, dass Architekten eine Architektur als Übung erstellen, ohne dass es eine Wissensvermittlung z.B. zu DDD gibt.
Das DDD-Architektur-Kata ergänzt das klassische Architektur-Kata um eine kurze Wissensvermittlung der wichtigsten DDD-Ansätze, die aber auch ohne Folien auskommt. Die Teilnehmer*innen wenden das Gelernte dann sofort selbst an und das nimmt auch den größten Teil der Zeit in Anspruch. Erst wenn man etwas selbst anwendet, hat man es verstanden. So macht sich das Format nicht nur das Wissen der Trainer zu Nutze, sondern auch das der Teilnehmer*innen. Schließlich haben viele schon umfangreiche Erfahrungen in der Praxis gesammelt, die sie bei ihren Lösungen einbringen können. Neben der Arbeit an der eigenen Architektur geben sich die Teilnehmer*innen auch gegenseitig Feedback zu ihren Lösungen. So lernt man gemeinsam nicht nur durch die eigenen Lösungen, sondern auch anhand der Ergebnisse der anderen Mitstreiter. Durch dieses Feedback durchdenken alle mehrere Lösungen, was dem Fokus der Kampfsport-Katas auf Wiederholungen entspricht.
Inhalte des DDD-Katas
Der DDD-Kata zeigt mit Event Storming zunächst einen Ansatz zur Analyse der Domäne mit Events, also fachlichen Ereignissen. Event Storming eignet sich hervorragend für das Kata-Format, weil der Hauptvorteil von Event Storming die Interaktivität ist und es zum gemeinsamen Arbeiten einlädt. Ein solches Konzept mit Folien zu vermitteln, erscheint schon fast absurd.
Der Fokus auf Events unterstützt einen anderen Blick auf die Domäne. Das erleichtert es später, Bounded Contexts zu finden, die meistens über Events kommunizieren. Gleichzeitig fangen die Events das Verhalten des Systems ein und damit einen ganz wesentlichen Aspekt, während sonst der Fokus oft eher auf einer Datenmodellierung liegt.
Die Aufteilung in Bounded Contexts ist die nächste Kata-Übung. Ein Bounded Context ist ein Teil eines Systems mit einem eigenen Domänenmodell. Wegen der getrennten Domänenmodelle sind Bounded Contexts weitgehend unabhängig. So kann z.B. ein E-Commerce-System einen Bounded Context für die Rechnungslegung haben und einen anderen für die Auslieferung der Waren. Sie haben unterschiedliche Domänenmodelle: Rechnungslegung betrachtet Preise, während die Auslieferung die Größe und die Gewichte der Waren einbeziehen muss. Änderungen an der Rechnungslegung werden typischerweise auf diesen Bounded Context beschränkt sein. Durch die verschiedenen Lösungen, die im Rahmen des Katas erstellt werden, können die Teilnehmer*innen über die Unterschiede und Gemeinsamkeiten reflektieren und nehmen so einen breiteren Eindruck mit.
Zwischen Bounded Contexts muss auch eine Kommunikation stattfinden: Eine Bestellung sollte eine Lieferung und eine Rechnung auslösen. DDD hält dafür im Strategic Design einige Pattern bereits. Auch diese Pattern vermittelt ein Kata, indem die Teilnehmer*innen die Aufteilung in Bounded Contexts mit Kollaborationen aus dem Strategic Design ergänzen.
Das gesamte Kata behandelt ein fachliches Beispiel. Die Trainer stehen dabei als “Kunden” für alle fachlichen Fragen bereit und als “Coaches” helfen sie den Teilnehmer*innen mit den zu erlernenden Techniken. So bilden die Katas ein echtes Projekt soweit ab, wie dies in der begrenzten Zeit möglich ist. Auch hier zeigt sich der Übungsaspekt des Katas als Vorbereitung auf den konkreten Einsatz im Projekt.
Fazit
Dieses Format haben wir für einen Kunden für die interne Weiterbildung entwickelt. Dort haben wir es schon öfter erfolgreich mit sehr positivem Feedback durchgeführt. Das Konzept der interaktiven Katas und der Fokus auf das “Selbst Machen” kommen bei den Teilnehmer*innen durchweg gut an. Auch auf einigen Konferenzen wie der JAX oder der OOP haben wir es schon als Tutorial gehalten. Deswegen freue ich mich darauf, den Tag mit den anderen Trainern zusammen auch als öffentliches Training durchzuführen und so noch mehr Interessierten DDD mit Katas zu vermitteln. Sehen wir uns dort?