Event Sourcing ist keine Nischenlösung, sondern ein leistungsfähiges Konzept

Allard Buijze ist Gründer und CTO von AxonIQ. Seine Leidenschaft für das Programmieren hat er bereits im Alter von sechs Jahren entwickelt. In seiner beruflichen Laufbahn begleitete er sowohl große als auch kleine Unternehmen bei der Entwicklung performanter und skalierbarer Anwendungen. Jetzt hat er es sich zur Aufgabe gemacht, die Implementierung von großen Systemen zu vereinfachen, indem er die Konzepte des Domain-driven Design, der Command-Query Responsibility Segregation (CQRS) und der Event-driven Architecture einsetzt.

iX: Wie sind Sie zum ersten Mal auf Event Sourcing als Architekturansatz gestoßen?

Das war irgendwann im Jahr 2009. Ich arbeitete damals noch für ein Beratungsunternehmen, bei dem ich für eine Reihe von Projekten verantwortlich war. Ich hatte die Nase voll davon, dass die Komplexität der Lösung am Ende viel höher war als die Komplexität des Problems, das wir damit lösen wollten.

Ich begann, mit verschiedenen Konzepten zu experimentieren. Domain-driven Design hat mir viel geholfen. Aber es musste noch etwas anderes geben.

Zu diesem Zeitpunkt sah ich eine Konferenzpräsentation von Greg Young. Er schlug vor, die Leseseite von der Schreibseite zu trennen. Er stellte auch das Konzept vor, alle Änderungen an einer Anwendung als Ereignisse darzustellen und zu speichern. Wir kennen diese Konzepte heute als CQRS und Event Sourcing.

Ich begann, mit diesen Ideen zu experimentieren. Das Ergebnis dieses Experiments wurde als Axon Framework bekannt.

Event Sourcing und Event Storming – ein kollaborativer Ansatz, um eine Domäne als eine Reihe von Domänenereignissen zu modellieren – klingen wie natürliche Ergänzungen. Können alle Event-Storming-Domänen mit Event Sourcing implementiert werden, indem man die Domänenereignisse speichert und wieder abspielt?

Event Sourcing passt in der Tat hervorragend zu Event Storming. Wir sehen auch, dass mit Event Modeling ein etwas anderer Prozess in der Event-Sourcing-Community immer beliebter wird.

Leider ist es nicht so einfach, Ereignisse zu speichern und dann Feierabend zu machen. Bei Event Sourcing muss man gut darüber nachdenken, wie man diese Ereignisse speichern kann, weil es eine Menge davon geben wird. Außerdem muss man in der Lage sein, sehr effizient auf sie zuzugreifen. Jedem, der sich in den Bereich des Event Sourcing wagt, empfehle ich dringend, ein vorhandenes Framework oder Tools zu verwenden, die für diese Aufgabe entwickelt wurden. Das wird Ihnen viel Zeit und Frustration ersparen. Kafka ist für viele Dinge gut, aber Event Sourcing gehört nicht dazu.

Aber die beiden gehen sehr gut Hand in Hand. Wenn Sie ein Event Sourced System aufbauen möchten, sollten Sie eine Technik wie Event Storming oder Event Modeling verwenden, um Ihre Domäne zu erkunden und Ihr System zu entwerfen. Denn hier liegt der Schwerpunkt darauf, was in einem System passiert, und nicht auf den statischen Datenattributen, die wir ihm zuweisen. Jeder datenorientierte Ansatz für den Entwurf eines Systems steht der Implementierung mit Event Sourcing im Weg.

Wie lässt sich am besten beurteilen, ob Event Sourcing die richtige Lösung für ein bestimmtes Problem ist?

Ich dachte immer, Event Sourcing sei eine Nischenlösung. Dass es nur dann sinnvoll ist, wenn Sie wirklich daran interessiert sind, die Historie Ihres Systems zu Revisionszwecken festzuhalten. Ich habe mich geirrt.

Event Sourcing ist ein leistungsfähiges Konzept. Es ermöglicht Ihnen, heute Informationen zu erfassen, die Sie vielleicht in der Zukunft brauchen. Viele Entwicklerinnen und Entwickler, mit denen ich spreche, wollen sich lieber auf das konzentrieren, was heute wichtig ist, weil man weiß, dass man diese andere Komponente später bauen kann. Auch wenn Event Sourcing mit einer gewissen Komplexität verbunden ist, ermöglicht es, mit komplexen Systemen viel besser umzugehen als mit traditionellen, datenorientierten Ansätzen. Außerdem erhalten Sie damit eine sehr zuverlässige Single Source of Truth, die Sie zur Fehlersuche in Ihrem System oder zur Erklärung von Anomalien in Ihren Daten nutzen können.

Um schnell herauszufinden, ob Event Sourcing die passende Methode ist, würde ich empfehlen, das System mithilfe von Event Modeling zu entwerfen. Wenn das gut funktioniert und sich das Verhalten eines Systems mit Befehlen, Ereignissen und Abfragen ausdrücken lässt, könnte Event Sourcing der richtige Ansatz sein.

Event Sourcing zwingt Entwickler und Entwicklerinnen dazu, sich auf das Verhalten eines Systems zu konzentrieren und nicht auf den Zustand. Das führt in der Regel auch zu einer besseren Abstimmung zwischen den Developern und den Anforderungen der Geschäftsinteressenten an die Software. Und wenn der Abstand zwischen Geschäft und Software kleiner ist, wird es einfacher zu erkennen, wo Änderungen vorgenommen werden müssen, um Änderungen der Anforderungen zu berücksichtigen.

Eine kleine Warnung für diejenigen, die sich zum ersten Mal an Event Sourcing wagen: Verwechseln Sie Event Sourcing nicht mit Event Streaming. Verwechseln Sie auch nicht die Lernkurve bei der erstmaligen Anwendung von Event Sourcing mit Komplexität. Es mag Aufgaben geben, deren Lösungsweg Sie kennen, die aber mit Event Sourcing schwieriger erscheinen. Das ist ein Teil der Lernkurve.

Haben Sie regelmäßig auftretende, unangemessene Entscheidungen in der Umsetzung von Event Sourcing beobachtet? Wenn ja, welche? Haben Sie eine Hypothese, warum diese Fehler häufig gemacht werden?

Ja, es gibt ein paar häufige Fehler. Der mit Abstand schwerwiegendste Fehler ist das Verwenden von CRUD-Ereignissen (Create, Read, Update, and Delete). Sie beschreiben die Datenänderungen und nicht das eigentliche Denken in der Geschäftslogik. Diese CRUD-Ereignisse sind in der Regel in der Zukunft viel weniger nützlich. Das bedeutet, dass wir ihre Vorteile nicht wirklich nutzen können, wenn wir sie aufbewahren.

Ich vermute, dass diese Fehler gemacht werden, weil wir darauf trainiert wurden, in relationalen Datenmodellen zu denken. Das fängt an der Universität an und setzt sich im Berufsleben fort. Bitten Sie einfach jemanden, Ihnen zu beschreiben, was ein System tut, und er beginnt in der Regel mit der Nennung aller möglichen Datenattribute.

Hier helfen auch Techniken wie Event Storming und Event Modeling. Sie konzentrieren sich wirklich auf das Verhalten und stellen den Zustand an die letzte Stelle. Beim ersten Mal wird es sich unangenehm anfühlen, aber in der Regel ist es danach sehr schnell selbstverständlich.

Wie würden Sie die Lernkurve eines Software-Engineers beschreiben, der erfolgreich mit dem Aufbau ereignisgesteuerter Systeme beginnen möchte? Sind besondere technische Fähigkeiten oder Methoden erforderlich? Haben Sie eine Empfehlung, wo man anfangen sollte?

Erfahrungsgemäß ist die Lernkurve für Event Sourcing nicht sehr steil. Ich habe zahlreiche Junior- und Senior-Entwickler, Architektinnen und sogar Geschäftsleute unterrichtet. Die größten Schwierigkeiten haben die Senior-Entwickler.

Es hat sich herausgestellt, dass das größte Problem tatsächlich die Entlernkurve ist. Was die meisten Leute zurückhält, ist die Abkehr von der Datenmentalität.

Mit den richtigen Werkzeugen und einer guten Entwurfsmethode, die die Ereignisse als Ausgangspunkt nimmt, sind die technischen Aspekte wirklich nicht so komplex. Einige sogenannte gängige Lösungen, die wir früher in unserem Werkzeugkasten hatten, sind inzwischen überholt. Für diese müssen wir andere Techniken erlernen. Am besten lernen wir auch, in größerem Umfang mit dem Modell der letztlichen Konsistenz umzugehen.

Am wichtigsten ist es, selbst Erfahrungen zu sammeln. Versuchen Sie, zunächst eine kleine, vereinfachte Version von etwas zu bauen, an dem Sie gerade arbeiten. Achten Sie auf die „Daten-Denkfalle“ und Sie werden feststellen, dass es gar nicht so schwer ist.

Das Interview führte Lukas Zühl

Software Architecture Gathering

Dieses Jahr findet das iSAQB Software Architecture Gathering 2024 wieder vor Ort statt. Für die internationale Konferenz am 12. und 13. November haben die Veranstalter, International Software Architecture Qualification Board (iSAQB) und iX, das Magazin für professionelle IT, Berlin als Veranstaltungsort ausgewählt. Vor und nach den Konferenztagen gibt es am 11. und 14. November zusätzliche Workshops.

Das Programm der Konferenz bietet 40 englischsprachige Vorträge und vier Keynotes, darunter

• Generative AI Meets Software Architecture
• Secure Architectures for AI-Based Software
• Can We Measure Developer Productivity?
• Modern Architectural Work: From Defining to Enabling
• Make Your Security Policy Auditable
• Domain-Driven Transformation – How to Improve the Structure of Legacy Systems

Allard Buijze hält auf der Konferenz den Vortrag "Event Sourcing – Technical Detail or Architectural Powerhorse?” über seine langjährigen Erfahrungen mit dem Aufbau von Event-Sourcing-Systemen.

(rme)