2012-04-18 12 views
5

Ich arbeite an einem CQRS/Event-Store-System. Im Moment ist das Muster, das ich verwende, für Befehle, um synchron zu sein. Das heißt, die Benutzerschnittstelle zeigt keine Operation als abgeschlossen an, bis der Befehl abgeschlossen ist, und der Erfolg/Fehler wird dem Benutzer angezeigt. Während der Ausführung der Befehle werden alle erzeugten Ereignisse (z. B. die Aktion X, die auf dem Gesamt-Wurzelverzeichnis Y aufgetreten ist) in einem dauerhaften Speicher gespeichert.Welche Vorteile bietet das Speichern von Befehlen in einem CQRS/ES-System?

Alle Beschreibungen von CQRS, die ich gelesen habe, implementieren Befehlsspeicher. Ich frage mich, ob dies in meiner Situation notwendig ist.

Eine andere Anmerkung - es gibt eine Menge lang andauernder Befehlstyp-Aktionen, daher habe ich Operationen in einen Befehl aufgeteilt, der Ereignisse generiert, und die Ereignisse wiederum geben mehr Befehle aus. Die Befehle sind idempotent, basierend auf dem Status des aggregierten Root. Ich weiß nicht, wie sich das auf die Antwort auswirkt, aber es lohnt sich, darauf hinzuweisen.

Danke, Erick

+0

Konnte einige Beispiele der Implementierung zur Verfügung stellen, die Befehle speichern? Die meisten Beispiele, die ich gesehen habe, speichern nur die Ereignisse, die als Ergebnis der Befehle erzeugt wurden. –

+0

Ich habe keine Frameworks, aber CQRS ohne Event Sourcing Records Befehle für die Wiedergabe, zumindest von meinem Verständnis. –

+0

Ich bin etwas besorgt über die Sicherheit. Was beabsichtigen Sie mit Befehlen wie ChangeUserPassword, das ein Klartextkennwort enthält? – Kimble

Antwort

6
  1. Regressionstests Nach jeder Iteration dev Sie Befehlsprotokoll von Produktionsumgebung greifen, führen Sie es erneut und Ereignisstrom mit einem auf die Produktion produziert vergleichen. Wenn sie anders sind - Sie haben eine Regression in Ihrer Logik.

  2. Nachrichtenflussvisualisierung und -analyse.

4

Die Beispiele für Cqrs, dass ich ohne Ereignis Sourcing gesehen habe, sind üblich relationale Datenbanken, die den Zustand des Systems zu speichern, anstatt Ereignisse, die zeigen, wie der Zustand der Daten über kamen. "Command Sourcing" ist ein neues Konzept für mich und scheint nicht richtig zu sein, da sich Command-Handler im Laufe der Zeit ändern können. Jegliche Änderungen an der Befehlshandlerlogik würden wahrscheinlich dazu führen, dass Befehle bei der Wiedergabe fehlschlagen. Bei der Wiedergabe von Ereignissen tritt dieses Problem nicht auf, da die Eigenschaften der Objekte direkt festgelegt sind.

+0

Das macht Sinn - danke! –