代码之家 › 专栏 › 技术社区 › tlt

使用嵌套对象和大集合进行聚合根优化

domain-driven-design

tlt · 技术社区 · 8 年前

让我们假设场景:

我们有 Users 系统的
每个 User 拥有他们的 Clients ( Client 总是分配给一个且只有一个 使用者 )
用户 上载不同的 Documents 和a Document 总是分配给一个且只有一个 客户

商业规则之一是 使用者 最多可以上载X 文件 总的来说,无论 客户 .

按惯例,我会 使用者 包含以下项的集合的聚合根: 客户 . 然后每个 客户 将收集 文件 已为该特定客户端上载。什么时候 使用者 尝试上载新 文件 对于给定 客户 ,我们将加载 用户 聚合根及其所有 客户 以及他们的 文件 ,和 使用者 类i的方法如下:

boolean CanUploadDocument()
{
  int numberOfDocuments = //Iterate Clients and sum up total number of their documents;

  //compare to maximum allowed number of docs for User instance
  return numberOfDocuments < this.maxAllowedNumberOfDocuments;
}

一切都很好,但是 maxAllowedNumberOfDocuments 可以是数千或上万,从db中加载它们只是为了计数,感觉太过了;比较它们。放 int documentsCount 在…上 使用者 似乎违反了规则,引入了不必要的冗余。

这种情况下会引入单独的聚合类根吗 UserQuota 在那里我们将加载所有 文件 检查一下?或者可能是一个价值对象 UserDocumentCount 哪个服务将获取并调用方法 使用者 对象:

boolean CanUploadDocument(UserDocumentCount count)
{
  //compare to maximum allowed number of docs for User instance
  return count < this.maxAllowedNumberOfDocuments;
}

什么是ddd;优化处理方法?

2 回复 | 直到 8 年前

Constantin Galbenu 8 年前

有一个大 User aggregate 不是一个解决方案,但不是因为它速度慢,需要优化,而是因为内部字段内聚。

为了保护配额限制 用户聚合 只需要上传的文件,没有更多。这表明你实际上有两个聚合,第二个是 UserDocuments 及其方法 uploadDocument . 该方法在内部检查引号不变量。作为优化,您可以保持 int countOfDocumentsUploadedSoFar 用于 上载文档 方法这两个聚合仅共享相同的标识(即 UserId ).

注意:两个聚合之间不需要继承。

poul_ko 8 年前

介绍如下内容 UserQuota 看起来是个不错的解决方案。这是一个真正的领域概念,它有权成为一个实体。刚才它有一个特性 DocumentsCount ,但到时候你可能需要 LasDocumentUploadedTime ... MaxAllowedNumberOfDocuments 也可以是配额的一部分,当这个数字发生变化时,这将有所帮助,并且变化应该只适用于新的配额,否则配额将变得更加个人化。

您的域操作也应该触及配额。例如,在上载文档时,您最初读取并检查了适当的配额,存储文档,然后更新配额。