Hochwertige Software durchDomain Driven Design – Teil 2

Intro / Was bisher geschah 

Im ersten Teil dieser zweiteiligen Blogserie zu Domain Driven Design (DDD) ging es um das Strategische Design. DDD hat die Ziele “Use a Ubiquitous Language” und “Make The Implicit Explicit” und erreicht damit im Strategischen Design die korrekte Modellbildung aller benötigten Anwendungsfälle einer Anwendung.  

Diese Ziele finden sich auch im taktischen Design wieder – die Modelle sollen nun so implementiert werden, dass die Software einfach erkennbar, änder- und erweiterbar ist und so langlebig und nachhaltig wird. 

Taktisches DDD 

Das taktische Design konzentriert sich auf den inneren Entwurf der Modelle. Es beschreibt die Form und Eigenschaften geschäftlicher Entities (wie „Order“), wie sie aggregiert werden und welches verlässliche Verhalten sie nach Außen haben. Interessanterweise kann man taktisches Design auch ohne vorgelagertes strategisches Design machen, wenn die Domänen klein sind und sich mit guter Erfahrung schneiden und beschreiben lassen. 

Business Rules 

Das Ergebnis des taktischen Designs ist eine Software-Architektur für den sogenannten „geschäftlichen Teil“ der Anwendung, das ist die Implementierung der wertschöpfenden Regeln des Unternehmens, wie z.B.  der Workflow einer Order und welche Bezahlungskriterien anzuwenden sind. 

Die Isolierung der Implementierung dieser Geschäftsregeln von allem anderen, was eine „live“-Anwendung braucht (z.B. eine Verbindung zu Systemen wie einem E-Mailserver, Dokumenten-Management, PIM-System, oder einem Techstack, in dem entwickelt wird und der Plattform-Komponenten zur Integration anbietet, beispielsweise eine konkrete Datenbank, oder ein konkretes Monitoring), ist der entscheidende Antrieb von taktischem DDD. Durch diese Trennung wird das Modell leicht pflegbar, weiterentwickelbar und sogar einfach portierbar. 

Architektur 

Das Ziel von taktischem DDD: das Modell völlig zu isolieren von „Infrastruktur“, lässt sich mit verschiedenen Architektur Paradigmen wie Clean Architecture, Onion Architecture, n-Layered Architecture oder Hexagonaler Architektur umsetzen. Es ist umgekehrt auch so, dass die Implementierung von Microservices in Hexagonaler Architektur das Entwicklungsteam direkt zu DDD-Methoden führt. 

Im folgenden Bild ist dargestellt, wie unser Domänenmodell aus dem ersten Beitrag zum strategischen Design mit einer hexagonalen Architektur implementiert sein könnte. Dabei wird in unterschiedlichen Architekturen – die sich in der Wahl und der Anordnung der „treibenden“ und „angetriebenen“ Adapter ändern können – eines immer gleichbleiben: Das Modell liegt im Zentrum, ohne Abhängigkeiten zu anderen Komponenten, da in der konzentrischen Architektur die Abhängigkeiten immer nach innen zeigen. Das Modell kann daher völlig autark „getrieben“ werden, was die Modellierung auf die Business Rules fokussiert, und cloud-native Entwicklung und Test ermöglichen.

Einschätzung

In der Frage nach Unterstützung von Qualitätskriterien wirkt sich taktisches Design besonders auf schnelle und vollständige Implementierung und das Erstellen und Pflegen vollständiger, automatisierter Tests aus. „Schnell“ bezieht sich hierbei auf die typische Geschwindigkeit von gut entworfenem und test-abgedecktem Code, der beispielsweise mit Test Driven Design erstellt wurde und damit bereits in einer Liga spielt, in der Wartbarkeit und Weiterentwickelbarkeit bereits wichtige Qualitätsrichtlinien waren.

Das taktische Design wirkt sich vor allem durch das Vorliegen von strengen und klaren Architekturrichtlinien für das Entwickeln aus. Auch das Testen wird durch die „Adaptertechnik“ besonders vereinfacht, weil das Handhaben der eigentlichen „Unit under Test“ einfach ist und nicht komplizierte Testharnesses aufgebaut und beherrscht werden müssen. 

Praktische Erfahrungen – oder: Events unter Expert:innen 

Nach den bis hier erfolgten Blicken auf die Theorie von strategischem und taktischem DDD-Design wollen wir noch jeweils auf Situationen sehen, die in der Praxis gerne, wie „Events“ im Domänenmodell vorkommen und dadurch noch weitere Einblicke in DDD verschaffen:   

Strategisches Design: Let’s meet Conway’s Law 

Wenn die Designphase für ein Software-Projekt beginnt und sich Fach- und Softwareexpert:innen in Workshops zum Modellieren des Problemspace treffen, dann kann es früher oder später zu dem Moment kommen, in welchem die Fachseite den Prozess verkürzen oder gar abbrechen will, weil für diese oder jene Domain oder Entity kein Begriff existiert oder bekannt ist und darum gebeten wird, „wir sollen doch irgendeinen Begriff“ nehmen. Solche Ausflüchte sind ein Event. 

Nicht, dass man auch mal kreativ sein muss, um z.B. Details der Core Domain zu beschreiben – wenn diese Blockade allerdings vermehrt auftaucht oder gar symptomatisch ist, zeigt sie, dass der Problemspace mindestens unter den Fachexpert:innen nicht präsent ist, wenn nicht gar überhaupt nicht korrekt genug definiert ist und noch optimiert werden muss. Das ist übrigens ein schönes Beispiel dafür, wie sehr IT (hier: Modellierung) und Business (hier: Core Domain) schon immer und insbesondere heutzutage miteinander verflochten sind. 

Es gibt viele Techniken, um den Problemspace miteinander zu modellieren, das macht erfahrungsgemäß den Fachexpert:innen auch viel Freude und sie sind gierig, Stück für Stück Transparenz in ihre Domains zu bringen. Aus projektplanerischer Sicht steht dann aber erst mal das Einschieben einer Basis-Designphase an. 

Taktisches Design: Moaning about Boilerplate-Code 

Es gibt sehr gut designte ShopSysteme. Zumindest auf der Code Ebene können wir das bewerten (das strategische Design liegt eher bei den Herstellern) – es gibt eine klare hexagonale Architektur, die die Modelle in Struktur und Bezeichnungen präzise in aller Deutlichkeit erkennen lassen. Ein oft beobachtetes Phänomen ist dann in Entwicklungsteams, die gerade neu mit dem Shopsystem beginnen, dass sich Developer über „den ganzen Boilerplate- Code“ beschweren. Denn scheinbar ist der Code überflüssig, weil man zum Beispiel beim Lesen über eine Kaskade von recht inhaltsarmen Quelldateien springen muss, bis man an der Stelle ist, „wo etwas passiert“. Oder man muss beim Schreiben diesen ganzen Code entweder manuell erstellen, oder man schlägt sich mit Generatoren herum, die es immer gibt, denn die Architekturregeln lassen sich automatisieren. Solche Beschwerden sind ein Event. 

Nicht, dass die Gefahr besteht, die Codebase durch Unkenntnis zu korrumpieren, hierfür sorgt schon die statische Codeanalyse in der Continuous Delivery, die eben genau jene Regeln der Architektur validiert. Es zeigt viel mehr, dass der Developer noch kein Verständnis von dem (strategischen und taktischen) Software- Modell hat und es treffsicher in den taktischen Design-Regeln implementieren kann.  

Erfahrene, gute Software-Entwickler:innen brauchen dann gar nicht lange, bis sie sich an das klare Design und die daraus folgenden Strukturen in der Implementierung gewöhnen. Ab dann haben sie immer ein Lächeln im Gesicht, wenn man mit ihnen über Changes spricht, weil sie schon im Gespräch wissen, an welcher vormaligen Boilerplate-Leerstelle sie hinmüssen und wie einfach die Adaption und der Test sind. 

Zusammenfassung/ Abschluss

Domain Driven Design ist sehr mächtig. Es gibt auch viele Methoden aus klassischen Disziplinen, die Vorgehensweisen von DDD ähneln und daher durchaus bekannt wirken. Im strategischen Design können das Projektmanagement,  Requirements Engineering oder Consulting sein. Im taktischen Design vor allem Pattern aus dem Cloud Native Umfeld wie CQRS, Event Sourcing oder Clean Architecture. Man könnte sagen, dass das, was DDD aus all diesen partikulären Wissensdomains (sic!) macht, ist sie in einem Gesamt-Domänendesign zusammenzufügen. Daher ist DDD mächtig und umfassend und es ist ein langer Weg, bis die Anwendung leicht aus der Hand geht. Die gute Nachricht ist, dass DDD kein Korsett ist, sondern auch im Einzelnen angewendet werden kann, immer mit dem Blick auf das Ganze!