Dynamic Consistency Boundaries: Flexible Konsistenz statt starrer Aggregates

Vielleicht kennen Sie das: Sie arbeiten an einem System mit Event-Sourcing (oder Sie möchten ein neues System damit aufbauen) und haben das Gefühl, dass Sie eigentlich schon recht weit sind. Sie haben eine gute Vorstellung davon, was Ihre Entitäten sind. Sie haben bereits erste Event-Typen formuliert, vielleicht sogar schon die ersten Commands. Doch dann kommt der Punkt, an dem Sie eine zentrale Frage beantworten müssen:

"Wie schneide ich eigentlich meine Aggregates?"

Und plötzlich wird alles kompliziert. Sie merken, dass die Entscheidung, wo Sie Ihre Konsistenzgrenzen ziehen, gar nicht so einfach ist. Sie ist im Gegenteil sogar eine der schwierigsten Entscheidungen in einem Event-getriebenen System und gleichzeitig leider auch eine der folgenreichsten. In diesem Blogpost möchte ich Ihnen zeigen, warum das so ist, warum Aggregates problematisch sein können und was Sie dagegen beziehungsweise stattdessen tun können.

Falls Sie mit Event-Sourcing noch nicht viel Erfahrung haben, empfehle ich Ihnen für den Einstieg zunächst das Video "Event-Sourcing – das einzige Video, das Du brauchst". Dort erkläre ich Ihnen ausführlich, was Event-Sourcing überhaupt ist, wie es grundsätzlich funktioniert, wie man Events schreibt und sie nachher wieder liest, und warum das Ganze überhaupt sinnvoll ist.

Willkommen in der Stadtbibliothek!

Lassen Sie uns mit einem Beispiel beginnen – einem Beispiel, das ich inzwischen in vielen meiner Beiträge verwende, weil es einerseits einfach genug ist, um anschaulich und übersichtlich zu bleiben, und andererseits genug Komplexität bietet, um echte Probleme sichtbar zu machen. Die Rede ist von einer fiktiven Stadtbibliothek. Dort können Leserinnen und Leser Bücher ausleihen, sie bei Bedarf verlängern oder irgendwann (hoffentlich zumindest) zurückgeben. Es gibt außerdem Vormerkungen, Mahnungen und manchmal auch Strafen in Form von Gebühren, zum Beispiel, wenn etwas zu spät oder beschädigt zurückgegeben wird.

Natürlich gibt es auch Regeln, wie das Ganze ablaufen soll, beispielsweise:

"Eine Leserin oder ein Leser darf maximal drei Bücher gleichzeitig ausleihen."

Oder:

"Ein Buch darf nur dann verlängert werden, wenn es nicht schon von jemand anderem vorgemerkt wurde."

Das klingt zunächst recht einfach. Wenn Sie die Vorgaben jedoch in ein Event-basiertes System bringen möchten, werden Sie schnell merken: Die Umsetzung ist alles andere als trivial. Ein wesentlicher Grund dafür liegt in den Aggregates, die übrigens ironischerweise eigentlich gar nichts mit Event-Sourcing zu tun haben, da sie ursprünglich ein Konzept aus dem Domain-Driven Design (DDD) sind.

Aggregates sind transaktionale Konsistenzgrenzen

In DDD, und damit oft auch im Event-Sourcing, sind Aggregates die zentralen Konsistenzgrenzen. Sie kapseln Geschäftslogik, sie schützen Invarianten, sie garantieren, dass innerhalb ihrer Grenzen keine fachlich ungültigen Zustände entstehen können, und so weiter. Wenn Sie zum Beispiel ein Book-Aggregate haben, muss es sicherstellen, dass ein Buch nicht doppelt ausgeliehen werden kann oder nur dann zurückgegeben werden kann, wenn es vorher tatsächlich ausgeliehen wurde. Das klingt zunächst sinnvoll, und in vielen Fällen funktioniert es auch gut. Aber eben nicht immer. Aggregates haben ihren Preis. Wie es im Englischen so schön heißt: There is no free lunch.

Das Schneiden eines Aggregate ist eine weitreichende Entscheidung. Es bestimmt nicht nur, wo Konsistenz gilt, sondern auch, wie Sie Events strukturieren, wie Sie Commands modellieren, wie Sie dementsprechend Ihre APIs gestalten, wie Sie Ihre Event-Streams aufbauen, wie Sie diese speichern und wieder lesen. Kurz gesagt: Es bestimmt einen großen Teil Ihrer (Daten-)Architektur. Genau deshalb ist diese Entscheidung so wichtig – und gleichzeitig auch gefährlich.

Sie müssen sie nämlich sehr früh treffen, oft bevor Sie überhaupt genau wissen, wie Ihre Domäne im Detail funktioniert. Sie treffen also eine Entscheidung mit großer Tragweite auf der Basis von sehr wenig Wissen. Und sobald Sie sie einmal getroffen haben, wird es sehr schwierig, sie noch einmal zu revidieren.

Das Schlimmste an alldem: Aggregates sind keine isolierten Konzepte. Sie beeinflussen Ihr gesamtes System. Sie können sie nicht einfach umschneiden. Sie können sie nicht zur Laufzeit neu anordnen. Sie können sie nicht modular ersetzen wie einzelne Services oder Datenbanktabellen. Wenn Sie ein Aggregate falsch schneiden, zahlen Sie diesen Preis oft über Jahre.

Ein Beispiel aus der Praxis

Um das anschaulich zu machen, nehmen wir noch einmal das Beispiel aus der Bibliothek: Wir hatten gesagt, dass eine Leserin oder ein Leser maximal drei Bücher gleichzeitig ausgeliehen haben darf. Wenn Sie nun sagen

"Okay, dann mache ich einfach ein Reader-Aggregate",

dann müssen Sie dort alle Ausleihen zusammenführen. Das bedeutet: Jedes Mal, wenn jemand ein Buch ausleihen möchte, müssen Sie alle bisherigen Ausleihen dieser Person kennen. Das wiederum bedeutet: Sie brauchen eine Event-Historie, die das abbildet – also einen Stream, der diese Informationen enthält. Doch was ist, wenn Sie stattdessen pro Ausleihe ein eigenes Aggregate haben wollen, also ein Loan-Aggregate?

Dann fehlt Ihnen plötzlich der Überblick: Sie wissen nicht, wie viele aktive Ausleihen es gibt, weil jede Ausleihe in einem eigenen Stream steckt. Sie müssten sie erst zusammenführen, was bei Event-Sourcing nicht trivial ist, da auf Event-Sourcing spezialisierte Datenbanken in der Regel keine Joins oder sonstige relationale Abfragen erlauben. Oder Sie entscheiden sich, das Buch als Aggregate zu modellieren. Dann steht die Regel aber völlig außerhalb des Kontexts dieses Aggregate, weil sie sich nicht auf ein einzelnes Buch, sondern auf die Summe der ausgeliehenen Bücher pro Leserin beziehungsweise pro Leser bezieht. Egal, wie Sie es schneiden – es passt nie so richtig.

Das Problem mit den Aggregates

Das eigentliche Problem: Aggregates sind statisch, viele Regeln sind in der Realität jedoch dynamisch. Aggregates sind strukturell, viele Geschäftsregeln dagegen semantisch. Aggregates orientieren sich an Objekten, viele Invarianten betreffen jedoch Beziehungen, Kombinationen oder Mengen. All das führt dazu, dass Sie Ihr Modell über kurz oder lang an die Struktur Ihrer Aggregate anpassen, statt Ihre Geschäftslogik so ausdrücken zu können, wie sie fachlich sinnvoll wäre.

Vielleicht war das früher weniger ein Problem. Solange Event-Sourcing ein Nischenthema für einige wenige war, konnte man sich mit komplexen Aggregates arrangieren. Das ändert sich jedoch derzeit. Event-Sourcing kommt langsam, aber stetig im Alltag an. Immer mehr Teams interessieren sich dafür, immer mehr Projekte setzen das Konzept produktiv ein. Websites wie CQRS.com und eventsourcing.ai oder Produkte wie EventSourcingDB (alle von the native web GmbH) tragen ihren Teil dazu bei. Doch je mehr Event-Sourcing in der Breite eingesetzt wird, desto mehr Menschen stoßen auf genau diese Fragen:

• Wie schneide ich meine Aggregates?
• Wie drücke ich Regeln aus, die sich nicht sauber in einem Objekt zusammenfassen lassen?
• Wie gehe ich mit Konsistenz um, wenn mehrere Dinge zusammenhängen?

Kurz: Was lange als Randproblem galt, wird für viele Entwicklerinnen und Entwickler zur Alltagsfrage. Wir brauchen Lösungen, die dem gerecht werden.

Eventual statt Strong Consistency

Es kommt noch etwas hinzu: Manche Regeln betreffen nicht nur mehrere Entitäten, sondern sogar mehrere Aggregates. Dann wird es richtig kompliziert. Stellen Sie sich vor, jemand möchte ein Buch verlängern. Um zu prüfen, ob das erlaubt ist, müssen Sie wissen: Ist das Buch aktuell überhaupt ausgeliehen? Ist es von der richtigen Person ausgeliehen? Ist es noch nicht vorgemerkt? All diese Informationen liegen in unterschiedlichen Kontexten vor: Die Ausleihe ist eine Transaktion zwischen der Leserin oder dem Leser und dem Buch. Die Vormerkung ist ein separater Kontext: Sie hängt zwar am Buch, ist aber kein Teil der Ausleihe. Die maximale Anzahl an Verlängerungen kann je nach Bibliotheksregelung ebenfalls eine Rolle spielen. Versuchen Sie, das alles in ein einziges Aggregate zu pressen. Das geht in der Regel entweder gar nicht oder nur um den Preis enormer Komplexität.

Viele Systeme akzeptieren in solchen Fällen die sogenannte Eventual Consistency. Das heißt: Sie lassen die Verlängerung zunächst durchgehen und prüfen dann asynchron, ob die Operation tatsächlich gültig war. Wenn nicht, erzeugen sie ein Kompensations-Event, schicken eine Benachrichtigung oder markieren den Zustand als ungültig. Das funktioniert technisch, ist aber aus fachlicher Sicht unsauber. Sie modellieren damit keine echte Invariante mehr, sondern einen nachträglichen Reparaturmechanismus.

Ergänzend enthalten viele Systeme sogenannte Prozessmanager oder Sagas, die diese Prüfungen orchestrieren. Sie führen mehrere Streams zusammen, lesen parallele Zustände, berechnen Ergebnisse und entscheiden auf Basis von Zeitverhalten, Idempotenz und Zustandskombinationen. Auch das funktioniert, ist jedoch schwer zu durchschauen, zu testen und zu warten. Oft ist es ein völlig überdimensioniertes Konstrukt für eine fachlich eigentlich einfache Regel.

Kill the Aggregate!

Genau deshalb stellt sich die Frage: Geht das nicht auch anders? Kann man Konsistenz nicht so modellieren, wie man sie eigentlich denkt? Also nicht in Form eines Objekts, das alles weiß, sondern in Form einer Regel, die einfach prüft: Gilt das, was ich fachlich will? Genau das ist die Idee hinter Dynamic Consistency Boundaries (oder kurz DCBs).

Dieser Begriff wurde von der italienischen Informatikerin Sara Pellegrini geprägt, die in einem Vortrag mit dem Titel "Kill Aggregate!" (nach einigen Minuten mit englischen Untertiteln) vor ein paar Jahren genau dieses Paradigma infrage gestellt hat: Muss Konsistenz wirklich immer an einem Objekt hängen? Oder geht es auch anders, nämlich dynamisch, operationsspezifisch und regelbasiert? Stellen Sie sich vor, Sie formulieren eine Regel nicht in Form eines Aggregate, sondern als direkte Bedingung auf die Event-Historie. Zum Beispiel:

"Zähle alle Events vom Typ bookLoaned, bei denen die Leser-ID 23 ist und für die noch kein bookReturned-Event existiert. Wenn die Anzahl kleiner als drei ist, ist die Operation erlaubt."

Das ist alles. Keine Aggregates. Kein Slicing. Keine Refactoring-Hölle. Keine Joins. Keine Prozessmanager. Keine Sagas. Einfach nur eine Regel: direkt formuliert, direkt überprüft und direkt durchgesetzt. Das ist die Stärke von Dynamic Consistency Boundaries: Sie machen die Konsistenzprüfung zum Teil der Operation und nicht zum Teil der Struktur.

Voraussetzungen für DCBs

Damit das in der Praxis funktioniert, müssen einige Voraussetzungen erfüllt sein. Erstens benötigen Sie Zugriff auf alle relevanten Events. Sie müssen also in der Lage sein, bestimmte Event-Typen zu filtern, zum Beispiel alle bookLoaned-Events für eine bestimmte Nutzerin oder einen bestimmten Nutzer. Zweitens brauchen Sie die Möglichkeit, Bedingungen zu formulieren. Sie wollen etwas ausdrücken können wie:

"Wenn Bedingung X erfüllt ist, dann (und nur dann) schreibe Event Y."

Drittens benötigen Sie ein System, das diese Bedingungen verlässlich prüft – serverseitig und atomar. Wenn Sie die Bedingungen im Anwendungscode prüfen und dann das Event schreiben, haben Sie wieder eine Race Condition. Diese drei Punkte zusammen bilden das Fundament für DCBs.

Genau das wird künftig zum Beispiel von der auf Event-Sourcing spezialisierten Datenbank EventSourcingDB unterstützt (die von meinem Unternehmen the native web entwickelt wird), und zwar über die eigens für EventSourcingDB entwickelte, deklarative Sprache EventQL. Sie können sich EventQL wie eine Art SQL vorstellen, nur für Events. Mit EventQL können Sie solche Regeln direkt formulieren und zukünftig beim Schreiben von Events in die EventSourcingDB als Vorbedingung angeben. Die Bedingung wird dann beim Schreiben des Events direkt im Server geprüft. Wenn sie erfüllt ist, wird das Event geschrieben. Wenn nicht, wird der Vorgang abgelehnt, und Sie können entsprechend reagieren. Das ist dann echte Konsistenz auf der Basis von realen Events – mit klaren Regeln, ohne Umwege.

Sie können damit Regeln abbilden, wie beispielsweise:

• Ein Gutschein darf nur einmal eingelöst werden.
• Ein Benutzername darf nicht doppelt vergeben sein.
• Eine Anwenderin darf sich nur einmal mit demselben Token einloggen.
• Eine Rechnung darf nur dann geschrieben werden, wenn der Auftrag abgeschlossen ist.
• Ein Buch darf nur dann zurückgegeben werden, wenn es vorher tatsächlich ausgeliehen wurde.

Werden klassische Aggregates überflüssig?

All das sind Beispiele für Regeln, die sich schwer oder gar nicht mit klassischen Aggregates umsetzen lassen – zumindest nicht ohne großen Aufwand und Nebenwirkungen. Mit Dynamic Consistency Boundaries und EventQL werden sie hingegen trivial.

Das bedeutet nicht, dass Aggregates vollständig überflüssig werden. Es gibt nach wie vor viele Anwendungsfälle, in denen sie sinnvoll sind, insbesondere wenn Sie komplexe Zustandsübergänge modellieren oder interne Logik kapseln möchten. Sie benötigen sie jedoch nicht mehr zwingend für jede Regel. Das ist der entscheidende Punkt. Sie können jetzt wählen: Sie können fachliche Regeln direkt ausdrücken, so wie Sie sie verstehen, und entscheiden, ob Sie dafür wirklich ein Aggregate brauchen oder ob eine dynamische Konsistenzgrenze nicht vielleicht die bessere Wahl ist.

(rme)