|
03.02.2026 10:13 Uhr |
Wenn Entwicklerinnen und Entwickler zum ersten Mal mit Domain-Driven Design (DDD), CQRS und Event Sourcing in Berührung kommen, bringen sie bereits mentale Modelle mit. Jahre der Arbeit mit Objekten und Tabellen haben geprägt, wie sie über Daten denken.
Und so haben sie sofort ein vertrautes Bild im Sinn, wenn sie das Wort „Aggregat“ hören: Ein Aggregat muss wie ein Objekt sein, und Objekte werden auf Tabellen abgebildet. Diese Intuition fühlt sich richtig an. Aber: Sie ist es nicht, und sie führt zu einem System, das verdächtig nach CRUD mit zusätzlichen Schritten aussieht.
Ich habe dieses Muster unzählige Male gesehen. Teams bauen etwas, das sie ein Event-getriebenes System nennen, und landen bei einer einzelnen books-Tabelle, die jedes Feld enthält, das ihr Book-Aggregat hat. Sie haben im Grunde eine relationale Datenbank nachgebaut, nur mit Events als Transportmechanismus. Die Stärken von DDD, CQRS und Event Sourcing, also die Flexibilität, die diese Konzepte versprechen – all das bleibt ungenutzt.
Das Problem ist das, was Entwicklerinnen und Entwickler typischerweise für ein Aggregat halten: einen Container für alle Daten über eine Sache. Sie stellen sich ein Book-Aggregat vor und beginnen, Eigenschaften aufzulisten:
Das sieht aus wie ein Objekt. Es hat alle Felder. Es lässt sich sauber auf eine Datenbanktabelle abbilden. Und genau darin liegt der Fehler: das Aggregat als Daten-Container zu behandeln.
Wenn Sie so denken, wird Ihr Aggregat zu einer aufgeblähten Repräsentation von allem, was Sie jemals über ein Buch wissen wollen könnten. Es spiegelt die Struktur Ihres Read Model wider, weil Sie noch nicht erkannt haben, dass es grundlegend verschiedene Konzepte sind, die grundlegend verschiedene Zwecke erfüllen.
Gemäß DDD ist ein Aggregat eine Konsistenzgrenze für die Entscheidungsfindung. Das ist alles. Sein Zweck ist sicherzustellen, dass Geschäftsregeln eingehalten werden, wenn Commands verarbeitet werden. Es benötigt nur die Informationen, die erforderlich sind, um zu entscheiden, ob ein Command gültig ist.
Betrachten Sie das BorrowBook-Command. Um zu entscheiden, ob ein Buch ausgeliehen werden kann, müssen Sie nur eins wissen: Ist das Buch derzeit verfügbar? Sie brauchen nicht den Titel, die Autorin oder den Autor, die ISBN, den Kaufpreis, den Standort oder das letzte Inspektionsdatum. Keine dieser Informationen hilft Ihnen zu entscheiden, ob dieses spezifische Command erfolgreich sein sollte oder nicht. Das heißt, das Aggregat kann sehr schlank sein, denn es enthält nur den entscheidungsrelevanten Zustand.
Für unser Bibliotheksbeispiel könnte ein richtig entworfenes Book-Aggregat daher folgendermaßen aussehen:
Das reicht aus, um zu entscheiden:
Alles andere, jede andere Information über das Buch, gehört woanders hin – und zwar in Read Models, nicht in das Aggregat.
Sobald Entwicklerinnen und Entwickler akzeptieren, dass ein Aggregat bestimmte Felder hat, folgt der nächste Fehler: „Wenn mein Aggregat diese Felder hat, sollte meine Read-Model-Tabelle diese Felder auch haben.“
Das Ergebnis ist vorhersehbar. Sie erstellen eine books-Tabelle mit Spalten für id, title, author, isbn, borrower, dueDate, location, condition, purchasePrice und jedes andere Feld, das Ihnen einfällt. Abfragen werden zu komplexen Joins über diese monolithische Struktur. Die Performance leidet. Die Flexibilität verschwindet.
Das ist CRUD-Denken, angewandt auf Event Sourcing. Die Events existieren, aber sie sind nur eine Transportschicht. Das System dreht sich immer noch um eine einzelne kanonische Repräsentation der Daten, genau wie eine traditionelle relationale Datenbank.
Read Models sind Projektionen, die für spezifische Abfragen optimiert sind. Sie dienen Anwendungsfällen, nicht Datenstrukturen. Und hier ist die entscheidende Erkenntnis: Read Models werden aus Events abgeleitet, nicht aus Aggregaten:
Es gibt keine Anforderung, keine Regel, kein architektonisches Prinzip, das besagt, dass Read Models die Struktur von Aggregaten spiegeln müssen.
Tatsächlich ist das Gegenteil wahr. Aus einem Event-Stream können Sie viele verschiedene Read Models bauen. Das ist die Stärke von CQRS, die verloren geht, wenn Sie in Tabellen denken.
Machen wir das konkret mit unserer Bibliothek. Wir haben ein Book-Aggregat, das Entscheidungen handhabt:
Events fließen durch das System: BookAcquired, BookBorrowed, BookReturned, BookRemoved und so weiter. Diese Events enthalten reichhaltige Informationen darüber, was passiert ist.
Betrachten Sie nun die verschiedenen Fragen, die Menschen beantwortet bekommen möchten:
Jedes davon ist ein separates Read Model, gebaut aus denselben Events, optimiert für seinen spezifischen Anwendungsfall.
So könnten diese Read Models aussehen:
Katalogsuche-Read-Model:
Ausleihenden-Dashboard-Read-Model:
Bibliotheksstatistik-Read-Model:
Überfällige-Bücher-Read-Model:
Bestands-Read-Model:
Jedes Read Model
Hier zeigt Event Sourcing seine wahre Stärke. Aus einem Stream von Events leiten Sie viele spezialisierte Read Models ab. Jedes ist klein, fokussiert und schnell. Das Hinzufügen eines neuen Read Model erfordert keine Änderung des Write Model oder bestehender Read Models. Sie bauen einfach eine weitere Projektion aus denselben Events.
Brauchen Sie einen neuen Bericht? Erstellen Sie ein neues Read Model. Müssen Sie eine langsame Abfrage optimieren? Strukturieren Sie dieses spezifische Read Model um, ohne irgendetwas anderes anzufassen. Müssen Sie einen neuen Anwendungsfall unterstützen? Fügen Sie eine weitere Projektion hinzu.
Diese Flexibilität ist das Versprechen von CQRS. Aber sie materialisiert sich nur, wenn Sie aufhören, Read Models als Spiegel Ihrer Aggregate zu betrachten.
Die praktischen Vorteile sind erheblich:
Der schwierigste Teil von Event Sourcing ist das Verlernen der mentalen Modelle, die Ihnen in CRUD-Systemen gute Dienste geleistet haben. Objekte und Tabellen sind nützliche Konzepte, aber sie sind nicht die richtige Linse, um Aggregate und Read Models zu verstehen.
Hören Sie auf zu fragen: „Welche Felder hat mein Aggregat?“ Beginnen Sie zu fragen: „Was muss ich wissen, um diese Entscheidung zu treffen?“
Hören Sie auf zu fragen: „Welche Tabelle brauche ich für dieses Aggregat?“ Beginnen Sie zu fragen: „Welche Fragen müssen meine Nutzerinnen und Nutzer beantwortet bekommen?“
Das Aggregat ist Ihre Entscheidungsgrenze, schlank und fokussiert. Events sind Ihre historische Aufzeichnung dessen, was passiert ist. Read Models sind Ihre optimierten Sichten für spezifische Abfragen.
Das sind drei verschiedene Konzepte. Sie müssen nicht dieselbe Struktur haben. Tatsächlich sollten sie es wahrscheinlich nicht.
(rme)