ドメインオブジェクトのアンダーロードを処理する共通のDDDパターンはありますか？

Question

アプリケーションで作業しているとき、特に適切なOODパターンとDDDパターンに従うときに、Customerなどのドメインクラスが生成されることがあります。それから、このオブジェクトをロードするいくつかのリポジトリがあり、すべてが素晴らしく清潔です。

アプリケーションが複雑になり、パフォーマンスが最適化されます。 Customerオブジェクトのリストをロードする必要はほとんどありませんが、IDと名前、またはプロパティの小さなサブセット（たとえば、グリッド内に表示するなど）を実際にロードする必要がない状況で自分自身を見つけることがあります。

私はよく見ている

ソリューションが含まれます：

1. アンダーロードドメインオブジェクトを、ので、基本的に我々はまだCustomerクラスを使用しますが、我々はそれらをロードするために別のリポジトリメソッドを使用して、そのリポジトリメソッドがロードしデータベースからは必須フィールドのみを検索し、オブジェクトの対応するプロパティに値を設定します。残りのCustomerフィールドはデフォルト値のままです。これは簡単な解決策ですが、開発者（または既存のコード）が特定のプロパティを読み込むことが予想される場合、多くのエラーが発生する可能性があります。私たちは私たちに必要なプロパティのみが含まれ、このようなCustomerIdName、CustomerInfo、CustomerHeaderなどのクラスを作成

2. 目的-クラス分け。このアプローチでは多数のクラスを作成できますが、慎重なサブクラス化は実行可能です。しかし、それはユビキタスドメイン言語のコンセプトから取り除かれているようです。

DDDの世界でそれらを処理するためのいくつかの一般的な合意がありますか？私はこれをgoogleにしようとしましたが、権威あるものを見つけることができませんでした。

これは古典的なDDDアプローチの周知の制限事項に過ぎず、CQRSや他のアプローチがこれらのシナリオでは良いでしょうか？

Answer 1

私は第二のアプローチは行く方法だと思います。 私たちのプロジェクトではそうしたやり方をしていますが、読み込み専用のDTOクラスについてのみ行っています。あなたが挿入/更新のためにそれらを使用していない限り、それはちょうどいいと思います。

あなたは多分に興味answerこともあります：

Answer 2

Entity Frameworkについて調べましたか？彼らはエンティティ遅延読み込みの複数のレベルを持っています：MSDN Post

Answer 3

それはDDDのよく知られた制限だとCQRSはそれを解決するために非常に良い方法です。読み出し側の

CQRSは基本的に変更可能なドメインエンティティを読み取りモデルの混乱を避けるためにすべての必要な予防措置との溶液＃2：なぜ荷重下など彼らのために無リポジトリ、読み取り専用のクラス、

Answer 4

私は理解していません問題になる可能性があります。あなたは無効なフィールドを知っているのでアクセス/遅延ロードをブロックできます