Snippets and Stories – ein Bericht vom Software Architecture Summit 2020
· Philipp
Entwicklerkonferenzen haben ihren eigenen Charme. Sie sind fokussiert, sie sind nerdig, ihr Netzwerken ist nicht durchgescriptet und es geht fast immer um die Sache. Es geht nicht darum, den nächsten Deal an Land zu ziehen und den dicksten Dienstwagen zu fahren. Es wird kein Quartalszahlenquartett gespielt. Vielleicht wird hier und da mal ein Bewerbungsgespräch eingefädelt – aber das ist dann auch schon das höchste der Gefühle. Wenn Entwickler sich auf Konferenzen treffen, teilen sie dort einen Teil von sich, eine Leidenschaft. Es geht darum, gemeinsam Technologien zu durchdringen, Best Practices auszutauschen, PoCs zu erbringen oder neue Methoden zu erlernen, zum Beispiel um Software domain-driven zu designen.
Natürlich geht es auch um das soziale Miteinander, um die stündlichen Snacks zwischen den Sessions und um den abendlichen Brauhausbesuch mit den Kollegen, der weit weg vom erhobenen Zeigefinger des Partners auch mal etwas länger gehen darf. Gemeinsame Erlebnisse außerhalb des beruflichen Korsetts schweißen zusammen – und auch wenn solche Abende manchmal mehr an eine Klassenfahrt erinnern mögen als an eine professionelle Fortbildungsmaßnahme, sind sie mindestens genauso wertvoll. Hier entstehen Freundschaften, hier wachsen Teams zusammen und legen den Grundstein dafür, die Zusammenarbeit auf ein neues Niveau zu heben.
So geschehen ist es erst kürzlich wieder auf der Software Architecture Summit in München, die ich zusammen mit drei Kollegen besuchen durfte. Die Konferenz wird von der Entwickler Akademie ausgerichtet und bietet eine Reihe von Expertenworkshops zu architektonischen Themen. In München lag der Schwerpunkt dieses Jahr auf Domain Driven Design. In den Sessions gab es eine erfrischende Tendenz zur praktischen Anwendung bis hin zum Mitmachen.
Warum DDD?
Der Talk von Golo Roden zu DDD, CQRS und Event Sourcing hat es mir besonders angetan und ich teile gerne ein paar meiner Eindrücke davon. In dem Talk ging es um folgendes Szenario: Ein Kunde möchte bei uns ein Spiel entwickeln lassen, bei dem der Spieler 42 Aufgaben lösen muss, um zu gewinnen (wie z.B. nevercompletedgame.com). Wir entwickeln das Spiel, wir prüfen die Antworten der Spieler auf Richtigkeit, wir speichern den Fortschritt des Spielers und gratulieren ihm, wenn er gewonnen hat. Der Kunde ist zufrieden, alles läuft. Allerdings hat er noch einen weiteren Wunsch. Er möchte wissen, wie viele falsche Antworten der Spieler gegeben hat, bevor er alle Aufgaben lösen konnte. Kein Problem, sagen wir, fügen einfach eine neue Spalte “wrong_answers” in der Datenbank hinzu und zählen hier die falschen Antworten des Spielers mit. Unser Kunde ist begeistert und möchte als nächstes natürlich auch noch wissen, bei welchen Aufgaben die falschen Antworten denn gegeben wurden. Kein Problem, sagen wir und fügen einfach die Spalten “wrong_answers_2” bis “wrong_answers_42” der Datenbank hinzu. Selbstverständlich beziehen sich die Ziffern im Spaltennamen auf die Aufgabe mit der gleichen Ziffer und unsere erste Spalte zum zählen der falschen Antworten gehört zu Aufgabe 1.
An dieser Stelle wurde mir klar: Auf diese Art die technische Lösung zu beugen, um die Wünsche des Kunden umzusetzen, erscheint nicht nur ziemlich bescheuert, sondern kommt mir leider auch ziemlich bekannt vor. Warum coden wir so? Warum legen wir beim Erstellen einer neuen Tabelle vorsichtshalber 200 zusätzliche „Value“-Spalten an, um auf zukünftige Anforderungen reagieren zu können? Warum gibt es Firmen, die in ihren eigenen Datensätzen im Feld V97 Faxnummern speichern, die aber nur dann als Faxnummern zu lesen sind, wenn gleichzeitig in V43 ein „Z“ steht? Dann ist es nicht verwunderlich, dass Entwickler als Übersetzer fungieren zwischen dem eigenen System und den anderen Mitarbeitern ihrer Firma. Dann ist es nicht verwunderlich, dass wir schon in Datenstrukturen denken, bevor wir überhaupt das fachliche Problem verstanden haben, das es zu lösen gilt.
Entwickler und Experten sprechen nicht mehr die gleiche Sprache
Create, Read, Update, Delete – diese vier Grundfunktionen für die Datenpersistierung wurden 1983 von James Martin formuliert und sind bis heute populär. 1983 brachte außerdem IBM seinen Personal Computer XT auf den Markt, standardmäßig mit 10 MB Festplatte. CRUD stammt aus einer Zeit, in der Daten teuer waren, knapp waren und Platz für neue Daten machen mussten, sobald sie nicht mehr gebraucht wurden. Deshalb war es sinnvoll, die Software dieser Gegebenheit anzupassen. Aber es war auch teuer, denn CRUD macht wachsende Systeme, die in der Zukunft auf unbekannte Anforderungen reagieren müssen, unflexibel. Noch schwerer jedoch wiegt der Keil, der dadurch zwischen fachliche und technische Abteilungen getrieben wird. Die Entwickler und die Experten sprechen nicht mehr die gleiche Sprache, die Kommunikation wird schwierig, die Zusammenarbeit wird mehr als lästig denn als fruchtbar empfunden.
Eine fachlich getriebene Alternative für die Konzeption von Software bietet Domain Driven Design, insbesondere in Kombination mit CQRS und Event Sourcing. Hierbei legt DDD großen Wert auf die Korrektheit bei der Ausarbeitung und Modellierung des entsprechenden Fachbereiches, mit dem sich die Software befasst. Mit Hilfe von Event Sourcing wird sichergestellt, dass wir jederzeit auf alternierende Anforderungen reagieren können. Durch das Trennen von lesenden und schreibenden Zugriffen auf das Datenmodell schließlich bietet CQRS Möglichkeiten für die Parallelisierung und Optimierung.
In dem zweiten Teil des Artikels erkläre ich DDD anhand eines Schachbeispiels von Golo Roden.