Ich bin neu in der CQRS / ES-Welt und habe eine Frage. Ich arbeite an einer Fakturierungs-Webanwendung, die Event Sourcing und CQRS verwendet.
Meine Frage ist dies - nach meinem Verständnis sollte ein neuer Befehl, der in das System kommt (beispielsweise ChangeLineItemPrice), das Domänenmodell durchlaufen, damit es als legaler Befehl validiert werden kann (zum Beispiel um zu prüfen, ob diese Werbebuchung tatsächlich existiert) existiert, der Preis verletzt keine Geschäftsregeln, etc.). Wenn alles gut geht (der Befehl wird nicht zurückgewiesen), wird das entsprechende Ereignis erstellt und gespeichert (z. B. LineItemPriceChanged)
Die Sache, die ich nicht ganz verstanden habe, ist, wie ich dieses Aggregat im Speicher behalten soll, bevor ich versuche, den Befehl anzuwenden. Wenn ich eine Million Rechnungen im System habe, sollte ich die gesamte Historie jedes Mal wiedergeben, wenn ich einen Befehl anwenden möchte? Speichere ich das Ereignis immer ohne Validierungen und führe die Validierungen beim Erstellen der Ansichtsmodelle / Projektionen durch?
Wenn ich irgendeinen Teil des Prozesses falsch verstanden habe, würde ich mich über Ihr Feedback freuen.
Danke für Ihre Hilfe!
Sie sind nicht allein, das ist ein häufiges Missverständnis. Lassen Sie mich zunächst den Validierungsteil beantworten:
In dieser Art von System gibt es zwei Arten der Validierung. Der erste ist der Typ, bei dem Sie nach gültigen E-Mail-Adressen, nur numerischen oder erforderlichen Feldern suchen. Dieser Typ wird ausgeführt, bevor der Befehl ausgegeben wird. Ein Befehl, der diese Art von Problemen enthält, sollte nicht als Befehl ausgelöst werden (für Gürtel und geschweifte Klammern können Sie auf der Domänenseite überprüfen, aber dies ist kein Domänenproblem und Sie sind besser dran, dieses Szenario zu verhindern).
Die nächste Art der Validierung ist, wenn eine Domäne betrifft. Es könnte die Art von Sache sein, die Sie erwähnen, wo Sie überprüfen, ob die Preise innerhalb bestimmter Parameter liegen. Dies ist ein Domänenkonzept, das die Geschäftsleute verstehen, tun und artikulieren können.
Die nächste Phase besteht darin, dass die Domäne die Statusänderung anwendet und die zugehörigen Ereignisse auslöst. Diese werden dann beibehalten und bei Erfolg für den Rest der App veröffentlicht.
All dies ist mit dem Aggregat im Speicher möglich. Die Aktionen werden mit einem Domänenservice koordiniert, der den Befehl verarbeitet. Es lädt das Aggregat, wendet alle es vergangenen Ereignisse an (oder lädt einen Snapshot) und gibt dann den Befehl aus. Bei Erfolg des Befehls fordert es alle neuen nicht festgeschriebenen Ereignisse an und versucht, sie beizubehalten. Nach dem Erfolg veröffentlicht es die neuen Ereignisse.
Wie Sie sehen, werden nur die Ereignisse für dieses spezifische Aggregat geladen. Auch bei vielen Ereignissen ist dieser Prozess blitzschnell. Wenn die Leistung ein Problem ist, gibt es Strategien wie das Speichern von Aggregaten im Speicher oder Snapshotting, die Sie anwenden können.
Zu Ihrem letzten Punkt über die Validierung von Ereignissen. Da sie nur von Ihrem Aggregat generiert werden können, sind sie vertrauenswürdig.
Wenn Sie weitere Details wünschen, werfen Sie einen Blick auf meine Übersicht über CQRS und ES hier . Und werfen Sie einen Blick auf meinen Post darüber, wie man aggregierte Wurzeln hier aufbauen kann.
Viel Glück - ich hoffe, sie helfen!
Es ist richtig, dass Sie das Ereignis wiederholen müssen, um das Domain-Aggregat zu "rehydrieren". Sie müssen jedoch nicht alle Ereignisse für alle Rechnungen wiederholen. Wenn Sie die Entitäts-ID des Stammaggregats in den Ereignissen speichern, können Sie einfach die Ereignisse mit der entsprechenden ID auswählen und wiedergeben.
Wie finden Sie dann die relevante aggregierte Root-ID? Eines der Lese-Repositorys sollte die relevanten Informationen enthalten, um die ID basierend auf einer Reihe von Suchkriterien zu erhalten.
Tags und Links domain-driven-design system-design event-sourcing cqrs