In meinem Artikel "Von AmigaBASIC bis KI" berichte ich von meinen Anfängen in der Programmierung: von der frühen Prägung durch BASIC bis hin zu den wilden Zeiten mit dem Amiga, der Demoszene und ARexx. Dieser Weg führte mich schließlich über ein Informatikstudium zur professionellen Softwareentwicklung mit OOP, PHP und PHPUnit.
Wie ich jedoch in "Testen mit und ohne Abhängigkeiten" beschrieben habe, war das Verständnis der Syntax nur der erste Schritt. Die eigentliche Herausforderung bestand darin, den Sinn hinter den Objekten zu verstehen. Die Unterscheidung zwischen identitätsbasierten Entitäten, austauschbaren Wertobjekten und zustandslosen Services war für mich ein fundamentaler "Aha-Moment". Es war der Punkt, an dem aus bloßem Code ein Modell der Wirklichkeit wurde.
Doch wie so oft in der Softwareentwicklung öffnet eine Antwort nur die Tür zu neuen Fragen. Nachdem ich gelernt hatte, wie wir Code strukturieren (Entitäten, Werte, Services), stand ich vor der nächsten großen Hürde: Wie modellieren wir Zeit und Veränderung?
Der nächste Schritt
Die Erkenntnis, dass nicht alle Objekte gleich sind, war mein Einstieg in das Domain-Driven Design (DDD). Während sich meine frühen OOP-Gehversuche stark auf den Zustand von Objekten oder die Daten in der Datenbank konzentrierten, lernte ich durch DDD, den Fokus auf das Verhalten zu legen.
Hier kam das Konzept der Command/Query Responsibility Segregation (CQRS) ins Spiel. CQRS lehrte mich, Lese- und Schreiblogik strikt voneinander zu trennen und sie nicht in denselben Klassen zu vermischen. Das Single Responsibility Principle, das "S" in "SOLID", lässt grüßen.
- Commands ändern den Zustand des Systems (Schreiben)
- Queries fragen den Zustand ab (Lesen)
Diese Trennung fühlte sich ähnlich wie die Befreiung an, die ich damals beim Übergang von prozeduralem Code zu echter objektorientierter Programmierung empfunden hatte. Plötzlich wurden meine Services schlanker und fokussierter.
Die Wahrheit liegt in den Ereignissen
Die radikalste Veränderung in meinem Denken brachte jedoch Event Sourcing. In "Testen mit und ohne Abhängigkeiten" habe ich Entitäten als Objekte mit einer Identität beschrieben, die über die Zeit bestehen bleibt. Traditionell speichern wir in relationalen Datenbanken jedoch nur den aktuellen Zustand dieser Entität. Alles, was davor geschah, wird dabei überschrieben und somit vergessen. Ein solches System wird auch als CRUD-System bezeichnet, wobei die einzelnen Buchstaben der Abkürzung für die Operationen Create, Read, Update und Delete stehen.
Event Sourcing dreht dieses Prinzip um: Anstatt nur das "Jetzt" zu speichern, speichern wir die Geschichte, also die Sequenz von Ereignissen (Events), die zu diesem Zustand geführt haben.
Dieser Ansatz machte die vagen Zustandsänderungen, die ich früher in meinen Entitäten versteckte, zu expliziten, fachlichen Fakten: "Bankkonto eröffnet", "Geld eingezahlt", "Geld abgehoben" und so weiter.
Vom Code zur Kommunikation
All diese technischen Muster – DDD, CQRS, Event Sourcing – sind zwar mächtig, lösen aber nicht das größte Problem der Softwareentwicklung: das Missverständnis zwischen Fachseite und Entwicklung.
Hier kommt die aus dem Collaborative Modeling stammende Methodik Event Storming ins Spiel. Die Grundlage bilden die Zusammenarbeit und der gegenseitige Wissensaustausch aller Beteiligten. Alle bringen ihre eigenen Perspektiven, Kompetenzen und Erfahrungen ein, sodass ein gemeinsames Verständnis des Problems entsteht. Dieses geteilte Verständnis bildet die Basis für die Entwicklung von Lösungen. Das Ziel besteht darin, durch die intensive Zusammenarbeit bessere Ergebnisse zu erzielen.
Anstatt allein im stillen Kämmerlein UML-Diagramme zu zeichnen (oder, wie in meinem Studium, auf Papier zu programmieren), bringt Event Storming alle Beteiligten in einen Raum. Mit unzähligen orangefarbenen Sticky Notes modellieren wir gemeinsam den Zeitstrahl der Domäne anhand von Ereignissen. Es ist faszinierend zu sehen, wie diese Methode die Lücke zwischen den Services sowie Entitäten im Code und den realen Geschäftsprozessen schließt.
Wie wertvoll dieser Austausch ist, erlebe ich jedes Jahr auf dem ComoCamp in Wien. Veranstaltungen wie diese zeigen, dass Methoden wie Event Storming keine theoretischen Konstrukte sind, sondern lebendige Werkzeuge, die gemeinschaftlich weiterentwickelt werden.
Fazit
Meine Reise begann mit print "Hello world" in AmigaBASIC und führte über die Entdeckung von Objekten zu einem tiefen Verständnis für Domänen und Ereignisse. Wenn ich heute auf meine Anfänge zurückblicke, erkenne ich eine klare Linie: Wir versuchen ständig, bessere Abstraktionen zu finden, um die Komplexität der Welt in Software umzusetzen.
Die Erkenntnis, dass nicht alle Objekte gleich sind, war wichtig. Doch der Schritt von "Wir speichern nur den aktuellen Zustand" zu "Wir protokollieren alle Ereignisse" war revolutionär.
Diese Konzepte zu verstehen ist eine Sache. Sie in die Praxis umzusetzen, insbesondere beim Testen, ist eine andere. In meinem nächsten Artikel untersuche ich, wie diese Muster von DDD, CQRS und Event Sourcing konkret zusammenkommen: wie wir unsere Tests an die Sprache des Event Storming anpassen, das Testen von einer Belastung zu einer Brücke machen und direkt aus unserer Testsuite eine lebendige Dokumentation generieren können. Die Theorie wird zur Praxis, und der Kreis von den Anforderungen über den Code bis zur Dokumentation schließt sich.
