Event Sourcing und Persistenz


11

Ich lese über Event-Sourcing und habe eine Frage zur Persistenz.

Ich kann immer noch eine Datenbank mit allen Entitäten haben, oder? Oder sollten die Ereignisse jedes Mal wiedergegeben werden, wenn die Anwendung gestartet wird, um die neueste Version jeder Entität im Speicher abzurufen? Scheint eine Verschwendung auf größeren Systemen zu sein (wie bei großen Datenmengen)?

Der Punkt bei der Ereignisbeschaffung ist, dass ich die Ereignisse wiedergeben kann, um bei Bedarf einen Datenspeicher zu füllen. (oder analysieren Sie die Daten)

Antworten:


9

Bei Event Sourcing lautet die Hauptfrage "Was ist Ihr Buch"?

Wenn Ihr Buch Ihr Ereignisstrom ist, haben Sie keine Probleme. Wenn Ihr Buch Ihr "Entitätsmodell" ist, treten überall Probleme auf. Ein Teil davon ist, dass Sie sagen können: "Wenn ich mein Entitätsmodell verloren habe, kann ich es aus meinem Ereignisstrom neu erstellen." Wenn Sie diese Frage positiv bewerten, ist Ihr Ereignisprotokoll Ihr Buch.

Es ist auch wichtig zu bedenken, dass die meisten Leute, die Event-Sourcing verwenden, ein Lesemodell verwenden. Dieses Modell wird zum Abfragen von Daten verwendet. Dies sieht jedoch eher wie ein 1nf-Modell aus als wie ein 3nf-Entitätsmodell. Sie wiederholen nur Ereignisse, um den Status von Aggregaten wiederherzustellen und festzustellen, ob Schreibvorgänge zulässig sein sollen.


Hallo Greg, ich bin neu im Event-Sourcing, aber ich möchte das wirklich beherrschen. Könnten Sie bitte einige Ressourcen für praktische Beispiele und Erklärungen vorschlagen? Ich habe viel über CQRS, ES gesehen und gelesen, aber wenn ich einen Prototyp starten möchte Wenn ich es benutze, kann ich wirklich nicht herausfinden, wo wann :) Ich hoffe, Sie können mir etwas vorschlagen (ich bin auf der Java-Seite). Vielen Dank für Ihre Zeit.
Vach

8

Sie profitieren am meisten von der Ereignisbeschaffung, wenn Sie sich entscheiden, auch Ihre Systemarchitektur zu ändern. Wenn Sie sich für eine Architektur im CQRS-Stil in Kombination mit DDD entscheiden, werden Sie zumindest meiner Meinung nach die wahren Vorteile eines Event-Sourcing nutzen.

Das Erstellen eines Ereignisspeichers, der sich in großen Systemen gut verhält, ist in der Tat keine leichte Aufgabe. Die Wiedergabe aller Daten kann in der Tat teuer sein und hängt stark von der Datenmenge ab, die wiedergegeben werden muss. Es gibt jedoch Techniken, die Ihnen dabei helfen können. Eine davon ist das Konzept eines Schnappschusses. Die Wiedergabe erfolgt nur ab einem bestimmten Punkt. Die Vorteile, die ein Event Store in Ihr System bringt, sind von unschätzbarem Wert. Wenn alles, was in Ihrem System passiert ist, wiedergegeben werden kann, sind alle Daten in jedem Moment eine großartige Sache. Denken Sie an Analysen, an die Fehlerreproduktion und an Statistiken.

Es gibt viele großartige Event-Stores, der letzte wurde erst gestern im Event Store veröffentlicht und scheint ein wirklich guter zu sein.

Die herkömmliche Datenbank kann für den Abfrageteil Ihres Systems aufbewahrt werden, um DTOs mit den angeforderten Daten aufzubauen. Diese Datenbank kann unter Berücksichtigung der Abfrageanforderungen Ihrer Anwendung und Ihrer Clients organisiert und optimiert werden.

Ich habe einen ausführlichen Artikel darüber geschrieben, was die Vorteile sind und wie eine CQRS-Architektur in Kombination mit Event-Sourcing wirklich aussieht. Sie können CQRS, Domain Events und DDD Review überprüfen .


1
Ich weiß alles über CQRS und DDD. Ich verstehe die Vorteile von Event Sourcing. Schnappschüsse sind eine großartige Möglichkeit, den Prozess zu beschleunigen. Das ist jedoch nicht Teil der Frage. Die Frage war jedoch eher, wo alle Modelle / Entitäten nach dem Laden gespeichert werden würden. Im Speicher (würde auf größeren Systemen viel Speicher benötigen) oder in einer Datenbank? Was ist die beste Vorgehensweise?
Jgauffin

1
Wenn Sie ein Aggregat neu erstellen, um einen bestimmten Befehl auszuführen, werden die Ereignisse wiedergegeben und das Aggregat im Speicher gehalten. Führen Sie die Aktion aus, generieren Sie die Ereignisse und speichern Sie die Ereignisse im Ereignisspeicher. Aber ja, das Aggregat mit seinen Wertobjekten und Entitäten würde im Speicher bleiben. Sie müssen nicht in einer anderen Datenbank gespeichert werden. Das ist normalerweise eine kurze Zeitspanne, bis der Befehl trotzdem ausgeführt wird. Wenn Sie Befehle haben, die sich über mehrere Aggregate erstrecken, was ein wenig unterschiedlich ist, kann dies auch auf einige Entwurfsprobleme mit Ihren begrenzten Kontexten hinweisen.
Vadim

1

Ich kann immer noch eine Datenbank mit allen Entitäten haben, oder? Oder sollten die Ereignisse jedes Mal wiedergegeben werden, wenn die Anwendung gestartet wird, um die neueste Version jeder Entität im Speicher abzurufen?

Die Antwort hängt von den Anforderungen Ihrer Anwendung ab. Ich habe es in beide Richtungen gesehen.

Ein äußerst erfolgreiches Softwarepaket für kleine Wirtschaftsprüfungsunternehmen liest jedes Mal beim Start das CQRS-Protokoll. Die Rohdatenmenge war relativ gering, sodass die Startzeit auch auf langsameren Computern unter einer Minute lag. Sie machen CQRS seit mehr als einem Jahrzehnt, bevor die Praxis populär wurde. Sie wussten, dass sie etwas Gutes vorhatten, als sie erkannten, dass sie ihre Kundendaten immer wieder aktualisieren können, ohne auf Probleme zu stoßen, die sie mit ihren größeren Systemen sehen.

In Systemen mit größeren Datenmengen und / oder Systemen, die für die Implementierung der Abfrageseite auf RDBMS-Funktionen angewiesen sind, verfügen Sie über eine Datenbank für die "aktuelle Ansicht" der ereignisbasierten Daten (Sie können sogar mehrere solcher Ansichten haben). Der Vorteil dieses Ansatzes besteht darin, dass Sie die Abfrageseite mit den bekannten Technologien erstellen können.


Welches Buchhaltungspaket macht das?
Magnus

@ user1420752 Axys .
dasblinkenlight
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.