CQRSイベントストアの集計と予測
CQRSイベントストアでは、「集計」にはイベントの要約ビューが含まれていますか、それとも単にそれらのイベントの境界への参照が含まれていますか？（グループID）
投影はイベントのビューまたは表現であるため、境界を表す集合体の場合は意味がありますが、集合体に現在の要約状態が含まれていると、2つの間の重複について混乱します。
CQRSイベントストアでは、「集計」にイベントの要約ビューが含まれていますか、それとも単にそれらのイベントの境界への参照が含まれていますか？ （グループID）
集合体はイベントストアに存在しません
- イベントはイベントストアに住んでいます
- 集計は書き込みモデル（CQRSのC）に存在します
この場合、集計は、 "Blue Book" ;と同じ基本的な意味を持ちます。これは、互いにすぐに一致する1つ以上のエンティティの周囲の境界の用語です。集合体の責任は、記録簿への書き込み（コマンド）がビジネス不変条件を尊重することを保証することです。
通常、イベントストアでは、イベントを「ストリーム」に整理すると便利です。 RDBMSスキーマ を想像すると、ストリームIDは、「これらのイベントはすべて同じ履歴の一部である」という識別子になります。
通常、1つのアグリゲート-> 1つのストリームの場合がありますが、常にそうであるとは限りません。モデルを変更するときに処理する必要がある例外的なケースがいくつかあります。グレッグ・ヤングは、これらのいくつかを彼の新しい イベントのバージョン管理に関するeBook でカバーしています。
そのため、同じデータ構造が集計側とクエリ側のストアに存在する可能性があります（異なる目的で使用される複製ビュー）。
はいといいえ。書き込みを検証するときに使用されるデータ構造が、クエリをサポートするために使用されるデータ構造と一致するのは絶対に事実です。しかし、ストレージは通常一致しません。言い換えると、アグリゲートは保存されません（アグリゲートのstateは保存されます）。一方、クエリビューがキャッシュされることはかなり一般的です（ここでも、データ構造自体ではなく、必ずしもすべてのイベントを再生する必要なしにデータ構造を再作成するために使用できる表現です）。
集約状態データ構造（rdbms）の例がある可能性はありますか？私が見つけたすべての例は、include id、source_id、versionなどのいくつかの列に切り詰められているため、集計のスコープを視覚化するのが困難です。
一般的な例は、トレーディングブック（「買い」と「売り」の注文の照合を担当する集合体）の例です。
従来のRDBMSストアでは、それはおそらく本のテーブルの行のように見え、本の一意のID、その本が追跡しているアイテムに関する情報、その本がいつアクティブであるかに関する日付情報などがあります。さらに、一意のID、トレーディングブックID、注文タイプ、トランザクション番号、価格、およびボリューム（つまり、不変条件を満たすために集計が知る必要のあるすべての情報）を含む、ある種の注文テーブルが存在する可能性があります。 。
ドキュメントストアでは、そのすべての情報が1つのドキュメントに表示されます。ルートオブジェクトに関する情報を含むjsonドキュメントと、注文オブジェクトの2つのリスト（1つは購入用、もう1つは販売用）です。
イベントストアでは、個々のOrderPlaced、TradeOccurred、OrderCancelledが表示されます。
スナップショットを保証するのに十分な大きさにならない限り、集計はイベントのセット全体を使用して計算されるようです。
はい、その通りです。 「フォールド関数」に精通している場合、イベントソーシングは一般的な初期状態からのフォールドにすぎません。スナップショットが利用可能になると、その状態からフォールドします（フォールドインされるイベントの数がそれに応じて減少します）
「スナップショット」を使用するイベントソース環境では、イベントストアとドキュメントストアの組み合わせが表示される場合があります（ドキュメントには、イベントストリームのどこでアセンブルされたかを示す追加のメタ情報が含まれます）。