私は CQRS を読んでいて、多くの原則が価値があることを発見しました。しかし、私には 1 つの大きな論点があります。多くの人が、読み取りモデルのクエリをビュー モデルの dto に直接マップすることについて話します。ここまでは順調ですね。しかし、私がよく耳にする「ビューごとに 1 つのテーブルまたは 1 つの選択」という言葉はどこから来ているのでしょうか。確かに、一部の画面は 1-1 を非常に簡単にマッピングします。しかし、ドロップダウンリストやウィジェットなどの参照データなど、複数の選択を伴う複雑な画面で日常的に作業しています...
複数の選択が必要なビューが簡単にわかりました。
ビューがシンプルでフラットな完璧な世界のシナリオで作業する以外に、どうすればこれを回避できますか?
しかし、私は日常的に、ドロップダウンリストやウィジェットなどの参照データなどの複数の選択を伴う複雑な画面を操作しています...
リスト、ウィジェットなどを選択します。これらはそれぞれ、別のビューにネストされたビューとして表示できます（すでに部分的なものである場合は明らかです）。そのように見ると、それぞれが独自のクエリを持つことができます。
私が扱ったシナリオでは、ビュー キャッシュを使用して、レンダリングするオブジェクトの事前計算されたビューを作成します。イベント (EDA を使用しています) が異なるドメインから発生した場合でも、ビュー キャッシュを維持するハンドラーがあるため、レンダリングしたい情報を複合 UI に適した状態にすることができます。私たちが目指している目標は、「select *」または「select * where ID =」をビュー キャッシュに対する唯一のクエリ形式にすることです。一部のページには複数の DTO がレンダリングされていますが、それらに参加する必要はありません。参加する必要があると感じた場合は、ビュー キャッシュに保存したい情報を含むメッセージを処理する前計算段階で参加します。
その答えは、「ビューを十分に非正規化したか?もっと事前に計算できたでしょうか?この情報をより適切に表現できたので、必要なクエリが少なくなったでしょうか?」という質問です。
「1 ビュー == 1 クエリ」を目指してください。そして、qstarin が述べたように、!= 画面を表示します。
これは、 Denormalizationを使用して回避できます。すべての高度なデータをフラット ビュー (結合なし) にする必要があります。第 1 正規形 (1NF または最小形)も参照してください。
CQRS では、読み取り側を可能な限り高速かつシンプルにするために使用されます。その結果、水平方向にスケーリングできます。