20

CQRS + イベント ソーシングを積極的に使用しているプロジェクトに移動しました。一見すると、それらすべての本やブログに従って実装されていますが、最終的に実装の何が悪いのかを理解しました。

CQRS アーキテクチャは次のとおりです。CQRS 設計

もともとここからこの写真を撮りました。

図でわかるように、読み取り側はキューからイベントを受け取り、それを 1 つずつさまざまなプロジェクション (デノーマライザー) のセットに渡します。その後、結果の ViewModel は AddOrUpdate メソッドを介して DB などに保存されます。写真からわかるように、デノーマライザーはイベント自体と読み取り側のデータベースからのデータのみに依存できます。例えば：

  1. アカウント ビューは既にデータベースに保存されています。
  2. EmailChanged イベントが到着
  3. DB から Account ビューを読み込みます
  4. 電子メールの変更を適用する
  5. Account を DB に保存します。

別のケース（いくつかのアイテムの数を数える、注文など）：

  1. OrderCreated イベントが到着
  2. NumberOf 以前に到着した注文を表す ViewModel を読み取ります
  3. これをインクリメントして保存します。

プロジェクトの内容: これらのイベントはすべて、ドメイン モデルで何かが変更されたことを通知する手段としてのみ使用します。したがって、私たちが行うこと：

  1. ドメイン リポジトリを取得し、必要なすべての集計を読み取ります。そうすることで、それらの最新の状態を取得します。
  2. ViewModel オブジェクトをゼロから構築するだけです
  3. 新しく作成したオブジェクトを Db に保存する

私たちのプロジェクトで使用するアプローチは、私には少し奇妙に見えますが、そのすべての欠点はわかりません。読み取り側を再構築する必要がある場合は、「アクティブな」デノーマライザーを追加し、次に特定のイベントを受け取ったときに、新しいビューモデルを再作成します。

本のアプローチを使用する場合、再構築のためにシステムのどこかに別のユーティリティロジックを用意する必要があります。これに必要なもの：

  1. 読み取り側をドロップ
  2. イベント ストアからすべてのイベントを最初から読み取る
  3. それらを投影に通す

私の質問は次
のとおり です。ここでの正しいアプローチは何ですか?

4

1 に答える 1

6

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

顕著な欠点の 1 つは、イベントの受信時に、対応する集計のリポジトリをさらに呼び出す必要があることです。これは、このリポジトリを直接またはサービスとして公開する必要があることを意味します。依存関係の増加に加えて、追加の IO があります。

イベントストアから再構築する場合、説明するアプローチは一般的に受け入れられている方法です。ここで説明するアプローチでは、プロジェクションの再構築専用のイベント ログを利用します。これは、再構築中のパフォーマンスの問題に対処するために使用できます。Scalable and Simple CQRS Views in the CloudとDDD /CQRS mailing list もご覧ください。

于 2013-04-16T23:48:37.270 に答える