Helena Henkel
Senior Developer
Was ist die OOP eigentlich?
Ich zitiere die Homepage:
Softwarearchitekt:innen, IT-Projektleiter:innen und Entwickler:innen setzen bei ihrer beruflichen Weiterbildung schon seit über 30 Jahren auf die OOP – der bekanntesten und größten Konferenz zu allen wichtigen Themen der Softwarearchitektur im deutschsprachigen Raum. Warum? Weil sie den bewährten Software-Szenetreff eingangs des Jahres darstellt und weil es ihr immer wieder aufs Neue gelingt, durch brandaktuelle, aber immer auch praxisnahe Vorträge ein zeitgemäßes Abbild gegenwärtiger Softwareentwicklung zu bieten.
In diesem Jahr hat Senacor mir die Gelegenheit gegeben, selbst einige Tage die Konferenz zu besuchen und mich zu verschiedenen Themen inspirieren zu lassen. Auf der OOP gibt es immer verschiedene Tracks und Schwerpunkte, die sich natürlich auch kombinieren lassen. Mein Schwerpunkt, über den ich in diesem Artikel berichten möchte, war „Domain Driven Design expands our horizons“.
Domain Driven Design
Der Kunde, bei dem ich aktuell im Einsatz bin, ist gerade in einer Umbruchphase und versucht, wie vermutlich viele unserer Kunden, mit Microservices, Domain Driven Design und Agiler Transformation die Komplexität zu beherrschen. Genau hier setzen viele der Konzepte an, die in einer Mischung aus zeitlos und brandaktuell aus verschiedenen Blickwinkeln vorgestellt und anfassbar gemacht wurden.
Grundlagen
Domain Driven Design (DDD) ist der Schnitt einer Fach-Domäne in überschaubare fachliche Zusammenhänge (Bounded Context), der genutzt wird, um technische Module aufzubauen. Um eine geeignete Unterteilung zu finden, lassen sich points of no return im Prozess nutzen, oder man schneidet entlang unterschiedlicher Fachabteilungen, die verantwortlich für Teilprozesse sind. Im DDD wird unterschieden in strategisches und taktisches Design. Das strategische Design meint hier die Vorarbeit, also Domänenschnitte im größeren Kontext, und das taktische Design modelliert in einer Granularität, mit der auch Entwickler arbeiten können, und nutzt als Arbeitsobjekte Entitys oder Value Objects. Die kreativen Methoden, um schnell und gezielt erste Schnitte visualisieren zu können, werden unter dem Begriff Collaborative Modeling zusammengefasst, besonders bekannt sind Domain Storytelling (man denkt in Szenarien und der Moderator zeichnet diese auf) und Event-Storming (gut skalierbar, weil alle gleichzeitig schreiben).
Erfahrungen aus der Praxis
Hat man diese Grundlagen verstanden, kann man in die komplexeren Vorträge einsteigen, beispielsweise von der beeindruckenden Carola Lilienthal das Thema Domain Transformation, wenn das Kind eigentlich schon in den Brunnen gefallen ist. Beliebte Klassifizierungsbegriffe sind der „Big Ball of Mud“ oder anämische Modelle, zusätzliche Herausforderung ist oft eine schlechte Organisation. Hier gilt es, die Domäne wiederzuentdecken, das fachliche Soll zu definieren, mit dem Ist-Zustand abzugleichen und anschließend umzubauen. Spannendes Detail des Vortrags waren hier die verschiedenen Domänentypen – ist die Domäne eine Pipeline, also ein klassischer Verkauf, bei dem erst alle Kundendaten erfasst werden, anschließend geprüft und irgendwann in ein Bestandssystem überführt, oder ist es eine Blackboard-Domäne wie zum Beispiel Veranstaltungsmanagement, wo tausend verschiedene Gruppen kleine Teilaspekte eines Teilnehmers benötigen, beispielsweise Unterkunft, Sessionteilnahme, Essensvorlieben. Oder landet man in der komplexen Dialogdomäne, in der verschiedene Gruppen aufeinander reagieren müssen nach bestimmten fachlichen Vorgaben?
Ein echter Geheimtipp war der Vortrag von Xin Yao. Ihr Thema hier auf der OOP war „sociotechnical design with DDD and friends“. Xin hat es als Geschichte erzählt – sie ging hinaus als junge Entwicklerin und wollte die Welt mit sauber strukturierter hochwertiger Software retten. Leider gab es so viele menschliche Loadbalancer zwischen Entwicklern und Anforderern, dass die Anwendung völlig am Bedarf vorbei entwickelt wurde und nie in Produktion ging, ich vermute, dass es nicht nur ihr so geht. Die Kern-Botschaft ist also ganz klar: so einfach wie mit Newtons Energieerhaltungsgesetz ist das nicht. Design passiert nicht in geschlossenen Systemen. Was kann man nun als Entwickler tun, um hier von unten (bottom up) bei der Transformation zu unterstützen? Es ist möglich, entlang der Wertschöpfungskette zuerst nach den Fertigkeiten (sog. capabilities) zu suchen und dann zurückzuverfolgen zum User. Im Zielbild muss man nach dem WARUM suchen – ganz praktisch anhand sozialer Erfahrungen und indem man ein Leitbild findet. Xin erklärt das, was auch Carola Lilienthal in ihrem Buch „Langlebige Software-Architekturen“ anreißt: Es gibt verschiedene Typen von Komplexität. Essenzielle Komplexität, also die notwendige fachliche Komplexität, ist gut. Es bedeutet, man hat etwas richtig gemacht, beispielsweise einen großen Kundenstamm oder viele Nutzer gewonnen und braucht dementsprechend ein System, das das abbilden kann. Problematisch ist die akzidentelle Komplexität, also Missverständnisse bezüglich Fachdomäne oder unnötige technische Komplexität. Als einen Ausweg nennt Xin das Thema „Enabling Constraints“, wie zum Beispiel bei uns im Scrum-Framework das Daily oder eine sticky-notes-architecture, bei der man jede Woche zusammenkommt und schaut, was sich getan hat. Für Interessierte kann Alicia Juarrero mit ihren Büchern und Vorträgen weitere Anreize und Ideen geben. Letztendlich geht es immer darum, das Spannungsfeld zwischen Stabilität und Veränderbarkeit auszubalancieren. Das ist nicht leicht, macht aber gerade auch das Spannende in unserem Job aus.
DDD-Fettnäpfchen und Praxisprobleme
Ein bisschen aus der DDD-Praxis hat Michael Plöd berichtet und vor zwölf typischen Fehlern gewarnt. Einige werde ich im Folgenden besonders hervorheben, weil sie etwas persönlich in mir bewegt haben.
Zunächst aber als Einstiegspunkt: Eine Kultur, die Dinge explizit kollaborativ macht, ist eine herausragend wichtige Grundvoraussetzung neben strategischem und taktischem Design, wie Michael Plöd betont und gleich als erstes Fettnäpfchen bezeichnet, diese zu vernachlässigen.
Der folgende Aspekt sind die Heilsversprechen: DDD löst alle Probleme, die man sich vorstellen kann. Hat man einen schwerfälligen Monolithen und Probleme mit der Wartbarkeit der Anwendung sowie eine stetig ansteigende Time to Market, dann genügen einige Workshops zu DDD und ein anschließender Schnitt des Monolithen in separate Teilanwendungen. Spoiler: nein. Vergessen wird oft, dass eine lose Kopplung nicht gleich eine Entkopplung von Teilanwendungen darstellt und man trotzdem noch Kommunikation zwischen verschiedensten Teams und IT-Systemen etablieren muss, um echten Businessmehrwert zu schaffen. Das reduziert die Komplexität oft nicht im erhofften Maß. Zudem ändert DDD nicht automatisch die Organisationsstruktur. Wenn man eigentlich nach wie vor im Wasserfall arbeitet, Anforderungen vorbeschätzen lässt und sie dann ausarbeitet und beauftragt, gibt es keine Vorteile mehr in der Time To Market, im Gegenteil, vielleicht werden sogar noch Komplexitätsebenen installiert, die vorher nicht existierten.
Als zweiten Aspekt möchte ich die fehlenden Domänenexperten betonen. Im Rahmen des Vortrags haben wir eine kurze Umfrage gemacht und viele der Teilnehmer aus unterschiedlichsten Branchen haben von diesem Schmerz berichtet. Wenn man keinen Zugang zu echtem Domänenwissen hat, fehlt dem Domain Driven Design erwartungsgemäß der Antreiber. Aus meiner eigenen Erfahrung heraus wird es dann zu einem interessanten Spannungsfeld, wenn ein Auftraggeber die Anforderungen maßgeblich mitgestaltet, der selbst keinen Zugriff zu Domänenwissen weiterer Domänen hat, die mit in die Software einfließen sollen. Erst in der Entwicklung kommen dann Fragen auf, die die Suche nach Domänenexperten dringlich und womöglich Livegang-gefährdend machen, nachdem vorher in verschiedenen Proxy-Schichten zwischen Anforderung und Entwicklung viel Wissen untergegangen ist. Michael Plöd schlägt vor, bei der Suche nach Experten kreativer zu werden und sie beispielsweise per Aushang am Kantineneingang zu suchen. Das erinnert mich an eine Situation in einem unserer agilen Reviews, als jemand plötzlich gefragt hat, ob denn eigentlich jemand vom Fachbereich da ist, und aus dem Off eine Stimme gesagt hat, „hier bin ich, ich bin der Fachbereich“. Vorher kannten viele von uns die Dame gar nicht.
Ein weiterer Aspekt ist das „uncollaborative modelling“ innerhalb der eigenen agilen Zelle. Das ist zum Beispiel eine Silobildung, bei der zwar Design- oder Fachexperten dem Team zugehörig sind, aber dann eine Übergabe an die Entwicklung machen, die dann in Release-Iterationen ohne direkte Feedbackzyklen die Features finalisiert. Aus der eigenen Arbeit bei den Kunden kann ich nur empfehlen, Berührungsängste immer wieder abzubauen: Features werden genau dann gerne „über den Zaun geworfen“, wenn die Fachseite permanent verunsichert ist, wie die Entwicklung reagiert und womöglich noch Kritik gespickt mit technischen Fachbegriffen äußert. Hier hilft es dann oft, einfach miteinander zu reden, Rückfragen besser zu erklären und Kontext und Intention für Anforderungen genauer einzuordnen, um Vertrauensverlust vorzubeugen. Der Speaker warnt zudem vor „Code Allergie“ und betont, dass eine Prototypenentwicklung Bestandteil des Designprozesses sein sollte.
Die späteren Beispiele im Vortrag beziehen sich vor allem auf Lerneffekte: wenn man sich selbst belügt, dass ein eierlegender Wollmilchkunde ein geeigneter Bounded Context ist, besteht wenig Raum für Verbesserung, ebenso, wie wenn man zögert, Fehler zu korrigieren, weil man viel Zeit und Geld in etwas investiert hat.
Abschließend lässt sich als Zuhörerin des Vortrags sagen, dass ich gerade, weil ich mich in meiner Kundensituation so oft ertappt gefühlt habe, viel daraus mitgenommen habe. Und den Gesamttenor der einleitenden Umfrage unter den Zuhörern, dass ein sinnvoller Domänenschnitt eines der schwierigsten Themen ist, mit dem man in der praktischen Arbeit konfrontiert wird, kann ich ebenfalls bestätigen.
Mein Fazit
Ein Teilnehmer auf der Konferenz meinte, Architektur ist praktisch, sie veraltet nicht so schnell. Da lohnt es sich sogar, Bücher zu schreiben. Dem anschließen möchte ich mein Fazit: die Einblicke, die ich in all den Vorträgen zu Domain Driven Design bekommen habe, werde ich noch über Jahre nutzen können. Sie geben mir eine Sprache, mit der ich mich zu Architekturthemen austauschen kann, und viele praktische Einblicke, die auch jetzt noch nachwirken und meine Arbeit ein bisschen spannender machen.
Für alle die zu DDD nicht genug bekommen können, hier noch einige spannende Links zum Thema: