引用はDDDからのものです：ソフトウェアの中心にある複雑さへの取り組み（150ページ）
a）
VALUEへのグローバル検索アクセスは、多くの場合意味があります。これは、そのプロパティによってVALUEを見つけることは、それらのプロパティを使用して新しいインスタンスを作成することと同等であるためです。例外があります。たとえば、オンラインでの旅行を計画している場合、予定されている旅程をいくつか保存し、後で戻って予約する旅程を選択することがあります。それらの旅程はVALUESです（同じフライトで構成された2つがある場合、どちらがどちらであるかは気になりません）が、それらは私のユーザー名に関連付けられており、そのまま取得されています。
Itinieraryクライアントがグローバルに検索しCustomer root entityてからこのItinieraryオブジェクトに移動するのではなく、バリューオブジェクトをグローバルにアクセス可能にする方が適切である理由について、作成者の理由がわかりません。
b）
永続オブジェクトのサブセットは、オブジェクト属性に基づく検索を通じてグローバルにアクセス可能である必要があります...それらは通常エンティティであり、複雑な内部構造を持つVALUEオブジェクトの場合もあります...
複雑な内部構造を持つValuesオブジェクトが、単純なValueオブジェクトではなく、グローバルにアクセス可能であることが一般的であるのはなぜですか？
c）とにかく、特定の値オブジェクトをグローバルにアクセス可能にする必要があるかどうかを判断する方法に関する一般的なガイドラインはありますか？
アップデート：
a）
旅程を顧客エンティティを通過可能にするドメインの理由はありません。動作に必要がないのに、なぜ顧客エンティティをロードするのですか？クエリは通常、動作ドメインを複雑にすることなく処理するのが最適です。
私はおそらくこれについて間違っていますが、ユーザー（つまり顧客ルートエンティティ）がログインすると、ドメインモデルがユーザーのを取得することは一般的ではありませんCustomer Aggregateか？
また、ユーザーがフライトを予約するオプションがある場合は、時々チェックすることもよくありますItineraries（ただし、英語は私の母国語ではないため、この用語Itineraryは実際には私が思っているものとは少し異なる意味になる場合があります）彼らは選択または予約しました。
また、Customer AggregateはすでにDBから取得されているItineraryので、一緒に取得されているのに、なぜ別のグローバル検索を発行するのでしょうか（おそらくDBで検索されます）Customer Aggregate。
c）
ルールは非常に単純なIMOです-必要がある場合。VO自体の構造には依存しませんが、ユースケースに特定のVOのインスタンスが必要かどうかに依存します。
しかし、このVOインスタンスは特定のエンティティに関連付けられている必要があります（つまりItinerary、特定のエンティティに関連付けられている必要がありますCustomer）。そうでない場合、作成者が指摘したように、プロパティでVOを検索する代わりに、これらのプロパティを使用して新しいVOインスタンスを作成できますか？
2回目の更新：
a）あなたのリンクから：
関係を表現する別の方法は、リポジトリを使用することです。
関係がリポジトリを介して表現される場合、プロパティを実装しSalesOrder.LineItemsますか（リポジトリを直接呼び出すエンティティに対してアドバイスするため、疑わしいです）、次にリポジトリを呼び出しますか、それとも次のようなものを実装しますSalesOrder.MyLineItems(IOrderRepository repo)か？SalesOrder.LineItems後者の場合、私は財産の必要がないと思いますか？
b）
覚えておくべき重要なことは、集計はデータの表示に使用されることを意図していないということです。
確かに、ドメインモデルは上位層がデータをどのように処理するかを気にしませんが、アプリケーション層とUI層の間でDTOを使用しない場合、UIは集約から表示するデータを抽出すると想定します（ UI全体に送信したと仮定します）集合体であり、その中に存在するエンティティだけではありません）？
ありがとうございました