Event Sourcing in der Praxis (Teil 2)
15.07.2019, 00:00 Uhr
Was bisher geschah…
Bei Event Sourcing wird nicht der Status quo eines Objekts gespeichert, sondern seine gesamte Historie. Wir stellen alle für den praktischen Einsatz nötigen Bausteine vor.
Die Grundlagen von Event Sourcing (ES) und dessen Umsetzung wurden im vorangegangenen Teil dieser Serie [1] mithilfe einiger Beispiele vorgestellt. Dabei hat der Artikel eine sehr technische Sichtweise eingenommen, die das Problem der Persistenz von Ereignissen in den Mittelpunkt stellte. Es wurde gezeigt, dass dafür nicht unbedingt eine NoSQL-Datenbank erforderlich ist, sofern der Einsatz einer solchen entweder nicht gewünscht oder nicht möglich ist. Die Bibliothek SQL Stream Store [2] emuliert einen Event Store auf Basis eines SQL Server. In der Umsetzung wurde die Bibliothek durch ein Repository gekapselt, das jede Art von Aggregat laden und speichern konnte.
Allerdings sind noch ein paar blinde Flecken auf der ES-Landkarte geblieben. Zunächst ist da das Thema der Abfragen. Da ein Event Store die Historie der Aggregate in Form von JSON-serialisierten Ereignissen enthält, ist es nicht möglich, spezifische inhaltliche Abfragen wie gewohnt über das Repository zu implementieren. Da das Repository deshalb nur über eine Get- und eine Save-Methode für alle Arten von Aggregaten verfügt, kam zudem die Frage auf, ob das Repository-Pattern überhaupt das richtige architektonische Muster für die Persistenz in ES-Systemen ist.
Jetzt 1 Monat kostenlos testen!
Sie wollen zukünftig auch von den Vorteilen eines plus-Abos profitieren? Werden Sie jetzt dotnetpro-plus-Kunde.
- + Digitales Kundenkonto,
- + Zugriff auf das digitale Heft,
- + Zugang zum digitalen Heftarchiv,
- + Auf Wunsch: Weekly Newsletter,
- + Sämtliche Codebeispiele im digitalen Heftarchiv verfügbar
