Replay-Ereignisse für Anpassungen

Question

Hypothetisch arbeite ich an einem System, das "Event Sourcing" (Speichern der Geschäftsereignisse) verwendet, die Kauf und Verkauf von Materialien hat; Irgendwann wird ein Bericht mit Preisen und Kosteninformationen generiert.

Stellen Sie sich vor, dass einer meiner Kunden mich anruft und sagt: "Die Kosten sind falsch, für mich sind die Regeln vom Profit auf diese Weise".

Ich könnte weitere Handler hinzufügen oder die Regeln ändern, um diesen speziellen Fall anzupassen, und die Ereignisse erneut abspielen.

Aber meine Frage ist, das ist der richtige Ansatz (oder zumindest der bessere)?

Answer 1

In einem Event-basierten System sind die Ereignisse unveränderlich - die einfachen Fakten dessen, was passiert ist. Das Umschreiben der Geschichte der Ereignisse ist etwas, was man einfach nicht tut [1].

Das Ändern der Berechnungslogik, die ein Ergebnis basierend auf diesen Ereignissen ableitet, ist absolut normal (es ist eines der wichtigsten Dinge, die selbst Sourcing ermöglicht).

Ob Sie tatsächlich Ihren Code ändern oder einen alternativen Algorithmus zur Verfügung stellen, ist eine Frage der Wahl - wenn das Original tatsächlich ein Bug war (klingt wie Ihr Fall), ändern Sie den Code. Wenn nicht, schreibe einen neuen.

In bestimmten Fällen (nicht allgemein empfohlen), funktioniert immer alles von den ursprünglichen Ereignissen; Wenn das der Fall ist, müssen Sie nur Ihre Ableitungslogik ändern, und Sie sind fertig.

In dem Fall, wo Sie haben die Ereignisse projiziert und denormalised in einem persistenten Speicher, und haben entschieden, dass die Situation einen Fehler darstellt, ist die normale Annäherung an:

1. Schlag weg die bestehenden denormalised Zustand
2. Wiederholung der Ereignisse die beabsichtigten alternativen Ableitung

Beachten Sie, dass dies nur dann ins Spiel kommt, wenn Sie zu erhalten habe einen nicht-ephemeren denormalisierten Staatsspeicher, der die Werte behält, die auf der Basis berechnet werden, die jetzt ersetzt wird. (Es ist durchaus zulässig, den denormalisierten Zustand in einen In-Memory-Stash zu projizieren; in einem solchen Fall ist das "Wegblasen" einfacher).

Ein anderes Szenario ist, wo Sie Snapshot-Optimierungen implementiert haben - in diesem Fall würde man auch neu zu Denormalisieren anders projizieren.

[1] Ja, es gibt exotische Fälle, in denen es gerechtfertigt werden kann, aber das ist ein .001% Fall