DDDパターンを使用しようとしていますが、永続ストレージとしてLiteDB、RavenDB、DocumentDBなどのNoSQLデータベースを使用することを検討しています。DDD NoSQLストレージとドメインモデルとビューモデル
私のドメインモデル（集約全体）をJSONドキュメントとしてシリアル化し、ドメインモデルからデータモデルへのマッピングを避けるDBに格納することができます。
しかし、データを画面に表示する目的でデータを読むのはどうですか。私のUIは、ビューモデルに基づいてビューを表示していますが、ビューモデルを構築する方法はありますか？私は文書DB経由で質問しますか？私のドメインモデルを作成し、それをモデルを表示するためにマップしますか？
「ドメインモデルをクエリに使用しないでください（モデルを読む）」と言われているので、私はこれを求めています。
私のドメインモデル（集約全体）をJSONドキュメントとしてシリアル化し、ドメインモデルからデータモデルへのマッピングを避けるDBに格納することができます。
うん、いいですね。
しかし、データを画面上に表示する目的では、そのデータを読むのはどうですか。私のUIは、ビューモデルに基づいてビューを表示していますが、ビューモデルを構築する方法はありますか？私は文書DB経由で質問しますか？私のドメインモデルを作成し、それをモデルを表示するためにマップしますか？
はい。興味深いのは、の場合、です。
リクエストと同期して作業を行うことができます。
リクエストと同期して処理を実行できますが、結果をキャッシュして、同じビューの後続のクエリが高速になるようにします。
バックグラウンドプロセスを使用してビューをキャッシュにロードすることで、すべてのクエリが高速になるように、非同期で動作させることができます。
基本的な考え方は、ドキュメントに変更を書き込むたびに、変更が発生したことを非同期プロセスに通知し、プロセスがキャッシュされたビューを更新するために必要なデータを読み込むことです。
「キャッシュ」は、たとえば、最近作成されたビューモデルを保持するドキュメントストアなどです。
キャッシュされたビューには、ビューを再構築する必要があるかどうかを要求時に判断できるメタデータも含まれます。 RFC 7234は、おそらくキャッシュメタデータについて考えるときには良い場所です。
Pawel氏によれば、書き込みモデルと読み取りモデルの分離は、cqrsという大きなテーマです。静かな文章がたくさんあります。 Martin Fowler's overviewから始めることをお勧めします。
私のプロジェクトはかなり小さく、バックエンドはなく、すべてがローカルで実行されていますが、まだ一部の部分でDDDを適用しようとしています。私はCQRSのように感じて、非同期の書き込み/読み取りは過度のものになるでしょう。 Pawełのように、私はむしろアプリケーションサービスで自分のVMを構築したいと考えています。現在私の懸念は、いくつかのプロパティと子コレクションを持つ集計がある場合ですが、これらのデータをリストに表示する目的でいくつかのプロパティを取得したいのですが、どうすればよいでしょうか？ ... >> –
... >>集約全体を取得し、2つのプロパティを持つVMを構築することは完全に無駄です。私は、常に2つのバージョンのドキュメントを作成する必要があるように感じます.1つは詳細用、もう1つはリスト用です。 –
ドメインモデルは、動作と状態の両方で構成されていることを理解することが重要です。永続する必要があるのは、状態だけです。
これを認識すると、集約状態がクエリを実行するのに怖いものではないこともわかります。しかし、読み込み/表示モデルの作成にはリポジトリを使用しないでください。単純なクエリで十分です。そこでは、ドメインオブジェクトの状態を単純なDTO（ドキュメント）に分割してデータベースに格納し、それらをドメインオブジェクトのプロパティとして保持すると便利です。これは本に示されているものとは少し異なりますが、実際にはうまくいきます。あなたが十分にカプセル化していて、シリアライゼーションとパーシスタンステストを書かないなら、少なくとも心配することはありません。 This articleには、ドメインオブジェクトがバックステートオブジェクトセクションの下に記載されています。
アプリケーションサービスでは、リポジトリを使用してNoSQLデータベースから集約を取り出し、別のビューモデルを使用してフロントエンドに渡します。このような問題に直面している場合は、CQRSに関する知識を得ることも検討してください。 –