イベントソースパターン：現在の状態を保存しないでください。

Question

私はイベントソーシングパターンを学んでいます。私は1つのことを理解できません。

への指示がありません。は、多くのチュートリアルでDBのエンティティの現在の状態を保存していません。開発者は、必要なエンティティに関連するDBからすべてのイベント（「イベントストリーム」）を抽出するためのインフラストラクチャを構築し、その後、新しい必要なタイプのオブジェクトに適用して最終的に現在の状態にする必要があります。

銀行口座にしてください。

1. エキス、その時点で、すべての関連イベント（おそらくDBで何千ものイベントがある）無料でお金の
2. 計算量を：私はしなければならない私のクライアント彼女の現在のアカウントの状態に戻ります。

ただし、パフォーマンスはどうですか？私はすべてのアカウントの現在の状態を保存する方が良いと思っています。新しいイベントはすぐにそれに副作用をもたらすでしょう。私は正しくないのですか？

Answer 1

イベントソーシングの全体のポイントは、状態を一連の変更として保持することです。したがって、現在の状態をESとは逆にします。

パフォーマンス要件のために、更新が最初から適用されるのではなく、スナップショットの転送からのみ適用されるように、時にはsnapshotが作成されることがあります。イベントストアは、イベントソーシングを使用するアプリケーションを対象とした特殊データベースであり、スナップショット機能out of the boxを提供できます。

他の部分は、ESが読み書きモデルを分離するCQRS - Command Query Responsibility Segregationパターンと相補的であるということです（以前のリンクではそれほど正しくはありませんでしたが、this oneを参照してください）。次に実行されているコマンドまたはドメインイベントは、現在の状態の非正規化された表現である読み取りモデルを継続的に更新するために使用されます。したがって、コマンドの場合は、イベント（ES）からドメインオブジェクトを作成して処理しますが、クエリの場合、イベントストアをバイパスし、リレーショナルデータベース、ドキュメントデータベースなどの最適化された読み取りモデルから直接データを取得しますあなたの読書シナリオのために。

ESで実装されているコマンド側のパフォーマンスよりも、主に読んでいるアプリケーションがある場合は、それほど重要ではないかもしれません。

ESのメリットはこの質問の範囲外であり、インターネットでかなりの情報を見つけることができます（特にGreg YoungとUdi Dahan）。私は個人的には少し懐疑的で、長時間実行しているビジネスシナリオを扱う場合は意味をなさないと思っています。