CQRS - モデルDTOの混乱を読む

Question

私はCQRSを読んで、貴重な原則の多くを見つけました。しかし、私には主な論点が1つあります。読まれたモデルクエリを直接モデルdtosにマップさせることについて多くの人々が話します。ここまでは順調ですね。しかし、 "1つのテーブルまたは1つのビューで選択する"はどこから聞こえるのですか？確かに、いくつかの画面は非常に簡単に1-1マップします。しかし、私は通常、ドロップダウンリスト、ウィジェットなどの参照データのようなものを複数選択する複雑な画面で作業します。

ビューがシンプルでフラットな完璧な世界のシナリオを扱うのではなく、これを避けるにはどうすればよいでしょうか？

Answer 1

しかし、私は日常などのリスト、ウィジェット、ドロップダウン内の参照データ のようなもののために複数の 選択を伴うだろういくつかの複雑な の画面で作業...

選択リスト、ウィジェットなどこれらのビューをそれぞれ別のビューにネストされたビューとして見ることができます（おそらく、それらがすでに自分の部分的なものである場合は明らかです）。そのように見れば、それぞれ独自のクエリを持つことができます。

Answer 2

「私は十分に私の意見を非正規化しましたか？事前に計算しておくことができますか？この情報をよりよく表現して、より少ないクエリが必要になるでしょうか？

「1 view == 1 query」のために努力してください。そして、qstarinによって述べられているように、view！= screen。

Answer 3

私が作業したシナリオでは、レンダリングしたいオブジェクトの事前計算されたビューであるビューキャッシュを使用します。イベント（私たちはEDAを使用しています）が異なるドメインから来た場合でも、複合UIに適した状態でレンダリングしたい情報を持つことができるように、ビューキャッシュを保持するハンドラがあります。私たちが目指しているのは、ビューキャッシュに対するクエリの唯一の形式である "select *"または "select * where ID ="を持つことです。いくつかのページには複数のDTOがレンダリングされていますが、参加する必要はありません。参加する必要があると感じる場合は、ビューキャッシュに保存したい情報が含まれているメッセージを処理する際に、計算前の段階でこれを行います。

Answer 4

これは、Denormalizationを使用して回避できます。洗練されたすべてのデータをフラットビュー（結合なし）にする必要があります。 First normal form (1NF or Minimal Form)もご覧ください。

CQRSでは、読み取り側をできるだけ速く簡単にするために使用されています。結果として、水平にスケーリングすることができます。