Neuronale Netze sind der Motor vieler Anwendungen in KI und GenAI. Diese Artikelserie gibt einen Einblick in die einzelnen Elemente. Der vierte Teil der Serie stellt die gängigsten Verlustfunktionen vor, leitet ihre Gradienten ab und zeigt dann, wie man die grundlegende Gradientenabstiegs-Aktualisierungsregel und ihre komplexeren Varianten entwickelt.

Um einem neuronalen Netzwerk nützliche Aufgaben beizubringen, müssen wir quantifizieren, wie gut seine Vorhersagen mit den Zielwerten übereinstimmen. Eine Verlustfunktion ist ein skalares Maß für den Fehler, den der Trainingsprozess durch Anpassung der Netzwerkparameter minimieren soll.

Mittlerer quadratischer Fehler für Regression

Wenn die Aufgabe des Netzwerks darin besteht, kontinuierliche Größen vorherzusagen, ist der mittlere quadratische Fehler eine naheliegende Wahl. Angenommen, wir haben einen Datensatz mit N Beispielen, wobei jedes Beispiel i einen Zielwert yᵢ hat und das Netzwerk eine Vorhersage ŷᵢ liefert. Der mittlere quadratische Fehler L ist definiert durch

L(ŷ, y) = (1/N) Σᵢ (ŷᵢ − yᵢ)²

Dieser Ausdruck summiert die quadrierten Differenzen zwischen Vorhersage und Zielwert über alle Beispiele und dividiert sie durch N, um einen Durchschnitt zu erhalten. Durch die Quadrierung des Fehlers werden große Abweichungen stärker bestraft als kleine, und durch den Durchschnitt wird der Verlust unabhängig von der Größe des Datensatzes.

Um zu sehen, wie dieser Verlust die Parameteraktualisierungen beeinflusst, berechnen wir seine Ableitung in Bezug auf eine einzelne Vorhersage ŷⱼ:

∂L/∂ŷⱼ = (2/N) (ŷⱼ − yⱼ)

Während der Rückpropagation wird dieser Gradient durch das Netzwerk weitergeleitet und steuert jede Gewichtsaktualisierung in Richtung einer Verringerung des quadratischen Fehlers.

In PyTorch schreibt man:

import torch
import torch.nn as nn

# Angenommen, `model` ordnet Eingaben den Vorhersagen ŷ der Form (batch_size, 1) zu
loss_fn = nn.MSELoss()  # erstellt ein Modul für den mittleren quadratischen Fehler
predictions = model(inputs)  # Vorwärtsdurchlauf erzeugt ŷ
loss = loss_fn(predictions, targets)

Hier kapselt nn.MSELoss() die obige Formel. Wenn wir später loss.backward() aufrufen, berechnet PyTorch ∂L/∂parameters automatisch, indem es die partiellen Ableitungen durch den Berechnungsgraphen verkettet.

Kreuzentropie für die Klassifizierung

Wenn die Aufgabe die Klassifizierung in eine von C Klassen ist, gibt das Netzwerk typischerweise einen Vektor von Logits z ∈ ℝᶜ für jedes Beispiel aus. Um diese Logits in eine Wahrscheinlichkeitsverteilung p umzuwandeln, wenden wir die Softmax-Funktion an:

softmax(z)ᵢ = exp(zᵢ) / Σⱼ exp(zⱼ)

Wenn die wahre Klassenbezeichnung für Beispiel i als One-Hot-Vektor y codiert ist, wobei yᵢ = 1 und yⱼ = 0 für j ≠ i, dann ist der Kreuzentropieverlust

L(z, y) = − Σᵢ yᵢ · log( softmax(z)ᵢ )

Da nur ein Eintrag von y ungleich Null ist, vereinfacht sich dies zu der negativen Log-Wahrscheinlichkeit, die der richtigen Klasse zugewiesen wird. Bei Verwendung von PyTorch’s nn.CrossEntropyLoss fusioniert die Implementierung die Softmax- und Log-Schritte auf numerisch stabile Weise und erwartet rohe Logits und ganzzahlige Klassenindizes:

import torch.nn as nn

loss_fn = nn.CrossEntropyLoss() # erstellt einen kombinierten Log-Softmax + NLL-Verlust
logits = model(inputs) # Form (batch_size, num_classes)
loss = loss_fn(logits, class_indices)

Im Hintergrund ist der Gradient von L in Bezug auf jedes Logit zₖ

∂L/∂zₖ = softmax(z)ₖ − yₖ,

was genau der Differenz zwischen der vorhergesagten Wahrscheinlichkeit und der tatsächlichen Beschriftung für jede Klasse entspricht.

Grundlegender Gradientenabstieg

Sobald ein Verlust festgelegt wurde, ist die einfachste Regel zur Parameteraktualisierung der Gradientenabstieg. Bezeichnen wir mit θ einen einzelnen Skalarparameter (einen Eintrag einer Gewichtungsmatrix oder eines Bias-Vektors) und mit L(θ) den Verlust als Funktion von θ. Die Gradientenabstiegsregel aktualisiert θ in Richtung des steilsten Abstiegs:

θ ← θ − η · ∂L/∂θ

Hier ist η > 0 die Lernrate, ein Hyperparameter, der die Schrittgröße steuert. Ein kleiner η-Wert führt zu einer langsamen, aber stabilen Konvergenz, während ein großer η-Wert dazu führen kann, dass der Verlust schwankt oder divergiert.

In der Praxis unterscheidet man drei Varianten: Wenn der Gradient vor jeder Aktualisierung über den gesamten Datensatz berechnet wird, spricht man von Batch-Gradientenabstieg; wenn für jede Aktualisierung nur ein einziges Beispiel verwendet wird, spricht man von stochastischem Gradientenabstieg; und wenn kleine Teilmengen von Beispielen (Mini-Batches) verwendet werden, spricht man von Mini-Batch-Gradientenabstieg. Mini-Batch-Aktualisierungen stellen einen Kompromiss zwischen verrauschten, aber schnellen stochastischen Aktualisierungen und stabilen, aber kostspieligen Batch-Aktualisierungen dar.

PyTorch bietet über das Paket torch.optim eine einfache Möglichkeit, Gradientenabstieg mit Mini-Batches durchzuführen. Um beispielsweise den einfachen stochastischen Gradientenabstieg mit Momentum zu verwenden, schreibt man:

import torch.optim as optim

optimizer = optim.SGD(model.parameters(), lr=0.01, momentum=0.9)
# für Eingaben, Ziele in data_loader: data_loader liefert Mini-Batches
optimizer.zero_grad()  # alle akkumulierten Gradienten löschen
outputs = model(inputs)  # Vorwärtsdurchlauf
loss = loss_fn(outputs, targets)  # Verlust berechnen
loss.backward()  # Rückwärtspropagierung zur Berechnung der Gradienten
optimizer.step()  # Parameter an Ort und Stelle aktualisieren

Der Aufruf von optimizer.zero_grad() löscht die Gradientenpuffer aller Parameter, sodass sich Gradienten aus früheren Iterationen nicht ansammeln. Der Aufruf von loss.backward() füllt das Attribut .grad jedes Parameters mit dem berechneten ∂L/∂θ, und optimizer.step() verwendet diese Gradienten, um die Parameter gemäß der gewählten Aktualisierungsregel zu aktualisieren.

Fortgeschrittene Optimierer: RMSProp und Adam

Während einfaches Momentum die Konvergenz in Tälern der Verlustfunktion beschleunigen kann, passen adaptive Methoden die Lernrate jedes Parameters individuell auf der Grundlage der Historie seiner Gradienten an. RMSProp behält einen exponentiell gewichteten gleitenden Durchschnitt der vergangenen quadrierten Gradienten bei:

sₜ = γ·sₜ₋₁ + (1−γ)·gₜ²

θ ← θ − (η / sqrt(sₜ + ε)) · gₜ

wobei gₜ = ∂L/∂θ zum Zeitpunkt t, γ typischerweise um 0,9 liegt und ε eine kleine Konstante für die numerische Stabilität ist. In PyTorch wird dies wie folgt konstruiert:

optimizer = optim.RMSprop(model.parameters(), lr=0.001, alpha=0.99, eps=1e-8)

Adam kombiniert Momentum und RMSProp, indem es sowohl einen gleitenden Durchschnitt der Gradienten mₜ als auch der quadrierten Gradienten vₜ beibehält und eine Bias-Korrektur anwendet:

mₜ = β₁·mₜ₋₁ + (1−β₁)·gₜ

vₜ = β₂·vₜ₋₁ + (1−β₂)·gₜ²

m̂ₜ = mₜ / (1−β₁ᵗ)

v̂ₜ = vₜ / (1−β₂ᵗ)

θ ← θ − η · ( m̂ₜ / ( sqrt(v̂ₜ) + ε ) )

mit den Standardwerten β₁=0,9, β₂=0,999 und ε=1e-8.

Im Code:

optimizer = optim.Adam(model.parameters(), lr=0.001, betas=(0.9, 0.999), eps=1e-8)

Jeder dieser Optimierer erfordert die Abstimmung seiner Hyperparameter – Lernrate, Abklingraten und Epsilon –, um die beste Leistung für ein bestimmtes Problem zu erzielen.

Der nächste Teil der Serie zeigt, wie diese Komponenten zu einer vollständigen Trainingsschleife zusammengesetzt werden. Anschließend untersucht er die Unterschiede zwischen dem Training mit und ohne explizite Minibatches und stellt Techniken wie Dropout und Gewichtsabnahme zur Verbesserung der Generalisierung vor.

(rme)

Am 7. August ist das von vielen mit Spannung erwartete GPT-5 erschienen. So offen OpenAI mit den wenige Tage zuvor veröffentlichten GPT-OSS-Modellen umgeht, so wenig ist über die Architektur von GPT-5 bekannt. Daher müssen viele Details Spekulation bleiben. Und wie so oft bei neuen Modellen gehen die Meinungen in der Community stark auseinander.

Spekulationen zur Architektur

Dass OpenAI einige Ideen für die GPT-OSS-Modelle dem kurz danach veröffentlichten großen GPT-5 entliehen hat, wäre anzunehmen. Vieles deutet aber darauf hin, dass GPT-5 nicht auf das schlanke MXFP4-Format setzt, das GPT-OSS so effizient macht. Die Gründe kennt nur OpenAI. Es ist schade, dass Unternehmen wie Anthropic, OpenAI und in gewissem Maße auch Google so wenig über die Architektur ihrer großen Modelle verraten.

Klar ist aber zumindest, dass GPT-5 ein sogenanntes Routing-Modell ist. Je nach Komplexität der Frage beantwortet das Modell sie entweder direkt oder gibt sie an ein Reasoning-Modell weiter, das dann versucht, das Problem strukturiert zu lösen. Leider klappt das nicht immer, wie die im Folgenden gezeigten ersten Versuche belegen.

Anders als die bisher von OpenAI veröffentlichten Modelle steht GPT-5 allen Nutzerinnen und Nutzern direkt zum Start zur Verfügung. Die interessante Strategieänderung könnte darauf zurückzuführen sein, dass das neue Modell dank Routing deutlich effizienter arbeitet und OpenAI damit Infrastruktur und somit Geld sparen kann, wenn möglichst viele das neue Modell nutzen.

OpenAI hat nach der Veröffentlichung von GPT-5 für viele User ältere Modelle wie GPT-4o und GPT-o3 in den unterschiedlichen Varianten nicht mehr bereitgestellt. Das Vorgehen hat OpenAI allerdings inzwischen korrigiert, sodass zumindest zahlende Kunden auch wieder alte Modelle wählen können.

Erste Chats mit GPT-5

Bei ersten Versuchen zeigt sich, dass GPT-5 Wissensfragen kompetent beantwortet:

Das Routing zu den Reasoning-Modellen funktioniert gut und verarbeitet den Erdbeertest korrekt. Im Netz kursieren aber auch Berichte über von GPT-5 falsch beantwortete Varianten der Strawberry-Challenge auf Englisch.

Bei komplexeren Fragen kommen allerdings nicht immer die richtigen Antworten heraus. Die Frage nach der Primfaktorenzerlegung von 2²⁰+1 beantwortet das Modell zwar eloquent und mit vielen Formeln, die Antwort ist aber leider falsch:

Ein interessantes Detail an dieser Konversation ist, dass GPT-5 manchmal die LaTeX-Notation verwendet, manchmal aber auch nicht. Offenbar hat es aus unterschiedlichen Trainingsdaten gelernt. Durch deren Harmonisierung könnte OpenAI sicher die Performance verbessern. Allerdings sind weder der Trainingsprozess noch die dazugehörigen Gewichte bekannt. Der Fehler in der Rechnung erklärt sich dadurch, dass 2²⁰+1 nicht durch 241 dividierbar ist, die richtige Primfaktoren-Zerlegung wäre 17*61.681, das richtige Ergebnis also 61.681.

Hinsichtlich des Trainings reicht das Wissen von GPT-5 wie bei GPT-OSS bis zum Juni 2024. Die im Artikel gezeigten Chats sind auf der ChatGPT-Seite zu finden.

Unterschiedliche Meinungen aus der Community

Erwartungsgemäß ist die Community in Bezug auf GPT-5 gespalten. User gewöhnen sich an Sprachmodelle wie an alte Freunde, und wenn sie plötzlich anders agieren, sind einige besonders begeistert, andere reagieren mit Ablehnung. Einige Meinungen treten auffällig häufig auf: weniger kreative Antworten, gut für die Softwareentwicklung geeignet, Enttäuschung im Vergleich zum Wettbewerb und Fortschritte beim Frontend.

Verringerte Kreativität: Nutzer kritisieren oft, dass das Modell weniger kreativ antwortet als die GPT-4-Modelle. Das könnte damit zusammenhängen, dass die Frage über das das Routing an ein simpleres Modell gelangt, das nicht über das notwendige Wissen für eine kreative Antwort verfügt.

Gut fürs Programmieren: Viele, die das Modell gut finden, sind besonders überzeugt von den Programmierfähigkeiten. Auch hier könnte ein Spezialmodell dahinterstehen, an das GPT-5 die Prompts weitergibt. Es ist denkbar, dass OpenAI dieses Modell mit gruppenbezogener Strategieoptimierung (Group Relative Policy Optimization, GRPO) trainiert hat, einer Methode, die das chinesische Unternehmen DeepSeek erfunden und veröffentlicht hat.

Vergleich mit Claude und Gemini 2.5 Pro: Viele Nutzerinnen und Nutzer sind enttäuscht und bevorzugen die Modelle von Anthropic und Google. Auch hier könnten Bias oder Gewöhnungseffekte eine entscheidende Rolle spielen. Harte Fakten wie die größere Kontextlänge (400.000 für GPT-5 im Vergleich zu bis zu einer Million Token bei anderen Anbietern) sprechen auch für die Modelle der Wettbewerber.

Frontend: Dass OpenAI mächtig aufgeräumt hat und unter anderem mehr Themes anbietet, sieht die Community allgemein positiv.

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)