体系结构 – 协调DDD,视图模型和性能

发布时间：2020-12-14 04:56:20 所属栏目：百科来源：网络整理

导读：我开始学习DDD并且关注从持久性中检索实体对象然后在UI的viewmodel中重构它们的性能影响. 假设我有两个聚合根： Person Orders------ -------personId orderIdname personId 每个聚合根都有自己的存储库,负责整个聚合的基本CRUD操作. 假设UI需要以下列： vie

我开始学习DDD并且关注从持久性中检索实体对象然后在UI的viewmodel中重构它们的性能影响.

假设我有两个聚合根：

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

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

假设UI需要以下列：

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

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

>急切加载所有人员实体,急切地加载基于personId的所有订单,将加载的实体重组为viewmodel.
>创建JOIN / COUNT(orderId)存储过程,并使数据库返回与viewmodel相同结构的数据.

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

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

基本上,如何将复杂的DDD聚合与自定义UI Viewmodels协调以保持性能？

更新

规格/查询对象

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

解决方法

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

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

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

这类似于read-model模式.

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!