CQRSを使用したサイド実装のアプローチを読む

Question

私は積極的にCQRS +イベントソーシングを使用しているプロジェクトに移動しました。最初の一見から、すべての本とブログに基づいて実装されましたが、最終的には、実装ではっきりとしたものが実現しました。ここで

はCQRSアーキテクチャです：

は、もともと私はhereからこの写真を撮りました。

読み込み側はキューからイベントを受け取り、それを1組ずつ異なる投影セット（非正規化器）に渡し、結果のViewModelがAddOrUpdateメソッドを介してDBに保存されます。だから私は写真から理解するように、非正規化はイベント自体と読み取り側DBのデータにのみ依存することができます。 例：

1. アカウントビューは既にdbに保存されています。
2. EmailChangedイベントが
3. に到着私たちは、私たちが戻ってDBにアカウントを保存し、それをメールで送信チェンジ
4. を適用DB
5. からアカウントビューをお読みください。

別のケース（一部商品の数を数え、注文を言う）：

1. OrderCreatedイベントが
2. に到着我々はのnumberOfが以前インクリメント
3. 注文を到着し、これを保存表しViewModelにをお読みください。

これらのイベントはすべて、ドメインモデルで変更された通知機能としてのみ使用されます。したがって、我々が行うこと：

1. 私たちはドメインリポジトリを取り、すべての必要な集約を読みます。そうすることで、私たちは彼らの最新の状態を取得します。
2. 私達はちょうど私たちは私たちのプロジェクトで使用したアプローチは、私には少し奇妙に見える、私はそれのすべての欠点を見ることができない

Dbのにスクラッチ

保存新しく作成されたオブジェクトからのViewModelオブジェクトを構築しかし、。読取り側を再構築する必要がある場合は、「アクティブ」な非正規化を追加し、次に特定のイベントを受け取ると、新しいビューモデルを再作成します。

私が本からのアプローチを使用する場合、再構築のために私のシステムのどこかに別のutilsロジックを持たなければなりません。我々はこのために必要なもの：読み出し側

1. ドロップ初め
2. からイベント・ストアからすべてのイベントが

予測を介してそれらを渡し読むだから私の質問は以下のとおりです。
ここで正しいアプローチは何ですか？

Answer 1

私たちのプロジェクトで使用しているアプローチは少し奇妙に見えますが、私は の欠点をすべて見ることはできません。

イベントの受信時に、対応する集合体のリポジトリに追加の呼び出しを行う必要があります。つまり、このリポジトリを直接またはサービスとして公開する必要があります。依存性の増加に加えて、追加のIOがあります。

イベント・ストアから再構築する場合は、一般に認められている方法で説明します。 hereに記載されているアプローチは、投影を再構築するための専用のイベントログを使用します。これは、再構築中にパフォーマンスの問題に対処するために使用できます。また、Scalable and Simple CQRS Views in the CloudとDDD/CQRS mailing listを見てください。