イベントストアではなく「スナップショット」プロジェクションから集計を再水和する

そのため、実際のプロジェクトにパターンを適用する機会は一度もありませんでしたが、しばらくの間、イベントソーシングとCQRSをいじっていました。

読み取りと書き込みの懸念を分離することの利点を理解しています。また、イベントソースとは異なり、イベントストアとは異なる「読み取りモデル」データベースに状態の変更を簡単に投影できます。

私があまりはっきりしていないのは、イベントストア自体から集計を再水和する理由です。

「読み取り」データベースへの変更の投影が非常に簡単な場合、スキーマがドメインモデルと完全に一致する「書き込み」データベースへの変更を常に投影しないのはなぜですか。これは、事実上スナップショットデータベースになります。

これは、ES + CQRSアプリケーションでかなり一般的だと思います。

この場合、イベントストアは、スキーマの変更の結果として「書き込み」データベースを再構築するときにのみ役立ちますか？それとも、もっと大きなものが欠けていますか？

私があまりはっきりしていないのは、イベントストア自体から集計を再水和する理由です。

「イベント」は記録の本だからです。

「読み取り」データベースへの変更の投影が非常に簡単な場合、スキーマがドメインモデルと完全に一致する「書き込み」データベースへの変更を常に投影しないのはなぜですか。これは、事実上スナップショットデータベースになります。

はい; 毎回その状態をゼロから再生成するのではなく、キャッシュされた集約状態のコピーを使用することがパフォーマンスの最適化に役立つ場合があります。覚えておいてください：パフォーマンスの最適化の最初のルールは「しない」です。ソリューションはさらに複雑になりますが、ビジネスの動機付けが得られるまで、それを避けることをお勧めします。

この場合、イベントストアは、スキーマの変更の結果として「書き込み」データベースを再構築するときにのみ役立ちますか？それとも、もっと大きなものが欠けていますか？

もっと大きなものが足りない。

最初のポイントは、イベントソースソリューションを検討している場合、何が起こったかの履歴を保存する価値があると期待するためです。つまり、非破壊的な変更を行いたいということです。

そのため、イベントストアに書き込みを行うのはこのためです。

特に、これはすべての変更をイベントストアに書き込む必要があることを意味します。

競合するライターは、互いの編集を認識していない場合、互いの書き込みを破壊したり、意図しない状態にシステムを駆動したりする可能性があります。したがって、一貫性が必要な場合の通常のアプローチは、ジャーナル内の特定の位置（HTTP APIの条件付きPUTに類似）に書き込みをアドレス指定することです。失敗した書き込みは、ジャ​​ーナルに対する現在の理解が同期していないこと、および回復する必要があることをライターに伝えます。

既知の良好な位置に戻ってから、追加のイベントを再生することは、そのポイントが一般的な回復戦略であるためです。既知の適切な位置は、ローカルキャッシュにあるもののコピー、またはスナップショットストア内の表現です。

幸福なパスでは、集計のスナップショットをメモリに保存できます。利用可能なローカルコピーがない場合にのみ外部ストアに連絡する必要があります。

さらに、記録帳にアクセスできる場合は、完全に追いつく必要はありません。

そのため、通常のアプローチ（スナップショットリポジトリを使用する場合）は、非同期に維持することです。そうすることで、回復する必要がある場合、集約の履歴全体をリロードしてリプレイすることなく回復できます。

有効期間が有効な細粒度の集計では、通常、スナップショットキャッシュの維持コストを上回るメリットを得るのに十分なイベントが収集されないため、この複雑さが重要ではない場合が多くあります。

しかし、それが問題に対して適切なツールである場合、古いモデルの集計を書き込みモデルにロードし、それを追加のイベントで更新することは、完全に合理的なことです。

「書き込み」データベースの目的が何であるかを指定しないので、ここであなたがこれを意味すると仮定します。イベントストアからアグリゲートを再構築する代わりに、アグリゲートに新しい更新を登録するとき、 「書き込み」データベースからそれを持ち上げ、変更を検証し、イベントを発行します。

これがあなたの言いたいことである場合、この戦略は不整合の条件を作成します。最後の更新が「書き込み」データベースに入る前に新しい更新が発生すると、新しい更新は古いデータに対して検証され、したがって、「不可能」（つまり「許可されない」）イベントを発行し、システム状態を破壊する可能性があります。

たとえば、劇場の座席を予約する常設例を考えてみましょう。二重予約を防ぐには、予約されている座席がすでに空いていないことを確認する必要があります。これが「検証」と呼ばれるものです。そのためには、すでに予約されている座席のリストを「書き込み」データベースに保存します。次に、予約リクエストが届くと、リクエストされた座席がリストに含まれているかどうかを確認し、含まれていない場合は「予約済み」イベントを発行します。次に、投影プロセスを実行します。このプロセスでは、「予約済み」イベントをリッスンし、「書き込み」データベースのリストに予約済みの座席を追加します。

通常、システムは次のように機能します。

1. Request to book seat #1
2. Check in the "already booked" list: the list is empty.
3. Issue a "booked seat #1" event.
4. Projection process catches the event, adds seat #1 to the "already booked" list.
5. Another request to book seat #1.
6. Check in the list: the list contains seat #1
7. Respond with an error message.

ただし、リクエストがあまりにも早く届き、ステップ4の前にステップ5が発生した場合はどうなりますか？

1. Request to book seat #1
2. Check in the "already booked" list: the list is empty.
3. Issue a "booked seat #1" event.
4. Another request to book seat #1.
5. Check in the list: the list is still empty.
6. Issue another "booked seat #1" event.

同じ座席を予約するための2つのイベントがあります。システム状態が破損しています。

これを防ぐには、予測に対して更新を検証しないでください。更新を検証するには、イベントストアから集計を再構築してから、更新を検証します。その後、イベントを発行しますが、タイムスタンプガードを使用して、ストアから最後に読み取ってから新しいイベントが発行されないようにします。これが失敗した場合は、再試行します。

イベントストアから集計を再構築すると、パフォーマンスが低下する可能性があります。これを軽減するために、スナップショットの作成元のイベントのIDでタグ付けされたイベントストリームに集計スナップショットを直接保存できます。この方法では、常に時間の初めからイベントストリーム全体を再生するのではなく、最新のスナップショットをロードし、その後に発生したイベントのみを再生することで、集計を再構築できます。

主な理由はパフォーマンスです。コミットごとにスナップショットを保存できます（commit = 1つのコマンドで生成されるイベント、通常は1つのイベントのみ）が、これにはコストがかかります。スナップショットに沿って、コミットも保存する必要があります。そうしないと、イベントソースになりません。そして、これらはすべて原子的に、またはすべてなしで行われなければなりません。質問は、個別のデータベース/テーブル/コレクションが使用されている場合にのみ有効です（そうでない場合は正確にイベントソーシングになります）。したがって、一貫性を保証するためにトランザクションを使用する必要があります。トランザクションはスケーラブルではありません。追加専用のイベントストリーム（イベントストア）は、スケーラビリティの母です。

2番目の理由は、集計カプセル化です。あなたはそれを保護する必要があります。これは、集計がいつでも内部表現を自由に変更できることを意味します。それを保存し、それに大きく依存している場合、バージョン管理に非常に苦労します。最適化としてのみスナップショットを使用する状況では、スキーマの変更時にそれらのスナップショットを単に無視します（単に？私は本当にそうは思いません。効率的な方法とその管理）。