3

イベント ソーシング ソリューションを使用してイベントを再生しているときに、イベントを状態に適用するときに、どのようなロジックを含める必要があるのか​​ 正確に疑問に思っています。

具体的には、検証について疑問に思っています。たとえば、次のいずれかのステータスになるエンティティがあるとします。

  • 記録された
  • アクティブ
  • 近い
  • キャンセル

進行状況は Logged->Active->Close または Logged->Active->Cancelled である必要があります。たとえば、Logged から Close に直接ジャンプすることはできません。

これで、検証はコマンドに含める必要があることを理解しましUpdateStateた。エンティティの現在の状態が目的の状態への遷移を許可するかどうかを確認StatusUpdatedし、イベント ストアに永続化される適切なイベントを生成します。

質問は、それを再生するときはどうすればよいですか? ステータスを更新するだけにするか、同じ検証を実行する必要があります (ステータス遷移要件が変更された場合、追加のロジックを追加しない限り、以前に更新されたエンティティを読み込めないようにする必要があります)。現在のロジックを満たさないエンティティはありますか?

PS。私の理解では、イベントは本質的に、すでに起こったことを「発表」するだけであり（送信者の状態はすでに変更されています）、関係者がそれに応じて反応できるようにするため、それを把握するのに問題があると思います。また、イベントのロード/再生の場合、実際に何かを「アナウンス」するのではなく、その状態を変更する必要があります...

4

2 に答える 2

11

イベント ストリームを再生するときに検証を実行する必要はありません。

コマンドは、将来実行されることをモデル化します。システムに何かを実行するように依頼します。ビジネスルールや検証などに基づいて、それを行うかどうかを決定するのはシステム次第です。

対照的に、イベントはすでに起こったことをモデル化します。現実と同じように、過去を変えることはできません。

したがって、これは、イベントが永続化されるとき、それが処理された時点で有効であると見なされたコマンドの結果であったことを意味します。イベント ストリームの再生とは、単に過去に何が起こったかを確認することを意味し、これを変更することはできません。

したがって、検証を再度実行する必要はありません。

さらに、これは、ある日ビジネス ロジックが変更された場合、過去に発生したすべてのこと (ビジネス アクシデント!) はまだ発生しているため、変更してはならないことを意味します。したがって、イベントを保存したときとは別の検証ロジックを使用できるため、検証ロジックを使用することはできません。

繰り返しますが、過去を変更することはできません (また、変更すべきではありません) :-)

例

クレジットカード番号を検証する方法があるとします。顧客があなたの店に来て支払いを行い、現在の一連のルールを考慮して、顧客のカードが有効であると見なすと、すべて問題ありません。

その後、ある日、クレジット カード協会がクレジット カード番号の計算方法を変更したため、別の検証アルゴリズムが使用されます。

過去のイベントを再生すると、新しい検証ルールの有無にかかわらず支払いが行われました。支払いが行われたという事実を変更することはできません。必要に応じて、新しいトランザクションを作成して顧客に返金する必要がありました。繰り返しますが、これは過去から変更されたイベントではなく、新しいイベントになります。

つまり、簡単に言うと、イベントを何に対しても検証しないでください。以前に発生したように、それらは定義上有効です。

于 2013-05-03T11:37:51.257 に答える
2

イベント ストアに書き込まれたすべてのイベント ストリームは、イベント ハンドラーにロジックを導入しなくても再生できるようにする必要があります。移行プロセスを変更する必要がある場合は、この例の行に沿って、何らかの変換を行うことを検討する必要があります。

最後のポイントについて。イベント ソーシングは、順序付けられたイベントの履歴レコードを使用して、エンティティの状態を永続化および復元するための手法です。エンティティを保存するときに、これらのイベントを公開して、関係者が消費できるようにすることもできます。

于 2013-05-03T11:31:26.143 に答える