6

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

假设我有两个聚合根：

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

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

假设 UI 需要以下列：

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

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

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

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

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

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

更新

规格/查询对象

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

4

2 回答 2

6

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

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

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

这类似于读取模型模式。

于 2012-08-21T17:32:51.907 回答
0

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

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

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

于 2012-08-21T09:05:27.087 回答