引述来自DDD：解决软件核心的复杂性（第 150 页）
一个）
对 VALUE 的全局搜索访问通常是没有意义的，因为通过其属性查找 VALUE 将等同于创建具有这些属性的新实例。也有例外。例如，当我计划在线旅行时，我有时会保存一些预期的行程并稍后返回以选择一个进行预订。这些行程是价值（如果有两个由相同的航班组成，我不在乎哪个是哪个），但它们已与我的用户名相关联并完整地为我检索。
我不明白作者的推理，为什么让Itinierary值对象全局可访问而不是客户端必须全局搜索Customer root entity然后从它遍历到这个Itinierary对象更合适？
b)
必须通过基于对象属性的搜索来全局访问持久对象的子集……它们通常是实体，有时是具有复杂内部结构的值对象……
为什么具有复杂内部结构的值对象更常见于全局可访问而不是更简单的值对象？
c) 无论如何，是否有一些关于如何确定特定值对象是否应该全局可访问的通用指南？
更新：
一个）
没有任何领域的理由可以通过客户实体进行行程遍历。如果任何行为都不需要客户实体，为什么还要加载它？查询通常在不使行为域复杂化的情况下得到最好的处理。
我对此可能错了，但是当用户（即客户根实体）登录时，域模型检索用户的不是很常见Customer Aggregate吗？
如果用户可以选择预订航班，那么他们也会经常检查Itineraries（虽然英语不是我的第一语言，所以这个词Itinerary实际上可能与我认为的意思有点不同）他们已经选择或预订。
既然Customer Aggregate已经从数据库中检索到，为什么在已经与 一起检索时发出另一个全局搜索Itinerary（可能会在 DB 中搜索它）Customer Aggregate？
C）
规则很简单 IMO - 如果有需要的话。它不取决于 VO 本身的结构，而是取决于用例是否需要特定 VO 的实例。
但是这个 VO 实例必须与某个实体相关（即Itinerary与特定实体相关Customer），否则正如作者指出的那样，我们可以简单地使用这些属性创建一个新的 VO 实例，而不是通过其属性搜索 VO 吗？
第二次更新：
a）从您的链接：
另一种表达关系的方法是使用存储库。
当通过repository表达关系时，您是否实现了一个SalesOrder.LineItems属性（我对此表示怀疑，因为您建议不要直接调用 repositories 的实体），而后者又调用了repository，或者您是否实现了类似的东西SalesOrder.MyLineItems(IOrderRepository repo)？如果是后者，那么我认为不需要SalesOrder.LineItems财产？
b)
要记住的重要一点是聚合并不意味着用于显示数据。
确实，域模型不关心上层将如何处理数据，但如果不在应用程序和UI层之间使用 DTO，那么我假设UI将提取数据以从聚合中显示（假设我们将整个发送到 UI聚合而不仅仅是驻留在其中的某个实体）？
谢谢