协调DDD，视图模型和性能

Question

我开始了解DDD并且关注从持久性中检索实体对象然后在UI的视图模型中重构它们的性能影响。

假设我有两个聚合根：

Person      Orders
------      -------
personId    orderId
name        personId

每个聚合根都有自己的存储库，负责整个聚合的基本CRUD操作。

假设UI需要以下列：

viewmodel
---------
personName
numberOfOrders

我可以想到两种方法可以填充这个视图模型：

1. 急切加载所有人员实体，急切加载基于personId的所有订单，将加载的实体重组为视图模型。
2. 创建一个JOIN / COUNT（orderId）存储过程，并让数据库返回与viewmodel相同结构的数据。

显然，选项1可能是非常昂贵的操作，因为可能有多个人和多个订单导致MULTIPLE数据库调用。选项2只需要一次数据库调用。

如果选项2是首选（高性能）选项，我在哪里存储这个“viewmodel”和所谓的“数据库调用？”在我可以实现的存储库之上是否有单独的“数据服务层”？或者这是关于DDD如何实施的反模式？

基本上，如何将复杂的DDD聚合与自定义UI视图模型进行协调以保持性能？

更新

规格/查询对象

在与朋友的谈话中，他曾建议可能的解决方案是某种规范/查询对象模式。唯一的问题是我们必须在存储库级别实现这一点，要求我将人员和订单组合成一个大的聚合。出于事务一致性的原因，我通常会避免这种情况。

Answer 1

您可以引入专用值对象和存储库，该存储库将返回给定人员的统计信息：

// value object
class PersonStatistics {
    String PersonName
    Int NumberOfOrders
    Money AverageOrderAmount
}

// repository
interface PersonStatisticsProvider {
    PersonStatistics Get();
}

这类似于read-model模式。

Answer 2

从性能角度来看，我会选择选项2，但可能会保留查询，该查询返回与返回订单数量的查询分开的人。

您可以通过类似OrderRepository.GetOrderCountByPerson(personId)之类的方式使订单计数可用，即使它与您的规范存储库定义略有不同。

通常，您从域实体派生ViewModel。让服务直接查询数据库以便它返回与ViewModel完全匹配的数据结构似乎很奇怪。