协调DDD、视图模型和性能

Question

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

假设我有两个总根：

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

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

假设UI需要以下列：

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

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

1. 急切地加载所有person实体，基于personId加载所有订单，将加载的实体重组到视图模型中。
2. 创建一个连接/计数(OrderId)存储过程，并以与视图模型相同的结构返回数据库数据。

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

如果选项2是首选(performant)选项，那么我应该将这个“视图模型”和所谓的“数据库调用”存储在哪里？在我可以实现的存储库之上是否有单独的“数据服务层”？或者，对于DDD的一般实现方式，这是一种反模式吗？

基本上，我如何协调复杂的DDD聚合与自定义UI视图模型，同时考虑性能？

更新

规范/查询对象

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

Answer 1

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

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

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

这类似于读模型模式。

Answer 2

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

您可以通过类似OrderRepository.GetOrderCountByPerson(personId)的方法使订单计数可用，即使它确实偏离了存储库的规范定义。

通常，您从域实体派生ViewModels。如果有一个服务直接查询数据库，从而返回一个与ViewModel完全匹配的数据结构，那就太奇怪了。