私はイベントソーシングについて読んでいて、書き込みが非常にまれであるか、軍事レベルの監査が必要なエキゾチックな状況でのみ意味があるかどうかを自問するのをやめられません。
重要な使用法がある例外的ではないシステムでは、1日あたり数百から数千の書き込みが発生する可能性があり、たとえば、1年間の操作で100万回または2回の書き込み（つまりイベント）に変換されます。現在の状態を取得するためだけに数百万のオブジェクト（イベント）をマージすることは、従来のストレージからのまっすぐな読み取りと比較すると、ばかげた命題のように聞こえます。それでも、イベントソーシングは、最もパフォーマンスの高いシステムの背後にあります（LMAXなど）。
それで、私は何が欠けていますか？イベントストリームからの状態の復元は一般的に行われていますか？または、これを行う必要がほとんどなく、代わりに通常の操作（つまり、CQRSからのクエリストレージを使用）に別のストレージを使用し、例外的な場合（レプリケーション、監査など）にのみイベントから復元するという考えですか？
回答:
それで、私は何が欠けていますか？
推測してください。
不足している可能性がある最初のことは、再構築している状態のイベントをリロードするだけでよいということです。トランザクション境界を適切にモデル化できる場合、各オブジェクトは独自のIDでタグ付けされたイベントを書き出し、それらのイベントのみを読み戻すことができます。イベントの格納にリレーショナルデータベースを使用すると、そのクエリを高速化するためのインデックス付きID列が存在します。EventStoreを使用すると、各オブジェクトに独自のストリームがあります。
各トランザクションで単一のオブジェクトのみを変更していることを確認したいので、モデルでこれをきれいに行うにはいくつかの注意が必要です。したがって、試行している各不変条件を正しく分離していることに注意する必要があります。実施する。
それでも十分に速くない場合でも、状態のスナップショット（メモ）を作成し、それを「従来のストレージ」に保持する可能性があります。各スナップショットには、スナップショットの作成に使用された最後のイベントのシーケンス番号がタグ付けされます。リロード時に、リポジトリは最初にそのスナップショットを取得し、次に新しいイベントを適用します。（これは、最新のスナップショットを取得するための合理的な方法を意味します。イベントにはシーケンス番号のタグも付けられるか、開始点に到達するまでイベントストリームを逆方向に読み取るための効率的な方法があります。）
ここで通常のアプローチよりも利点があります。スナップショットは、マージするのではなく、書き込みと並行して構築できることです。イベントリスナーを他のスレッド/プロセスに配置し、書き込みに合わせて楽しませるだけです。適切なスケジュールでスナップショットストアに移動します。結局のところ、スナップショットは特にタイムリーである必要はありません-新しいイベントを再適用する作業がSLAに影響を与えないほど頻繁に。
（スナップショットは移行を複雑にします。モデルのシリアル化に変更を加えると、スナップショットキャッシュが無効になります。もちろん、移行の一部として新しいシリアル化を使用してスナップショットを再構築し、変更が有効になったときに「追いつく」ことができます。）
イベントストリームからの状態の復元は一般的に行われていますか？
はい、そうです。通常CQRSの例に示されているのは、アプリケーション層が、送信されたコマンドが適切に形成されていることを確認した後、リポジトリからドメインオブジェクトをロードすることです。 （または、イベントのリストを含むファクトリーへの呼び出し）。
他の2つの矛盾した考え。