gpt4 book ai didi

domain-driven-design - 使用嵌套对象和大集合聚合根优化

转载 作者:行者123 更新时间:2023-12-05 03:07:19 26 4
gpt4 key购买 nike

让我们假设场景:

  1. 我们有系统的用户
  2. 每个 User 都有他们的 Clients(Client 总是分配给一个且只有一个 User)<
  3. Users 上传不同的 Documents 并且 Document 总是分配给一个且只有一个 Client

业务规则之一是 User 总共可以上传 X 个 Documents,而不管 Clients 的数量。

根据本书,我将使 User 成为聚合根,其中将包含 Clients 的集合。然后每个 Client 都会有为该特定客户端上传的 Documents 集合。当 User 尝试为给定的 Client 上传新的 Document 时,我们将加载 Users 聚合根及其所有 Clients 和他们的 Documents,在 User 类上,我有这样的方法:

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 可以是数千或数万,从数据库中加载它们只是为了计算和比较它们感觉像是一个巨大的矫枉过正。将 int documentsCount 放在 User 上似乎违反了规则并引入了不必要的冗余。

在这种情况下是否需要引入像 UserQuota 这样的单独聚合根,我们将只加载所有 Documents 的计数并进行检查?或者可能是一个值对象 UserDocumentCount,该服务将在 User 对象上获取和调用方法:

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

处理此问题的 ddd-proper 和优化方法是什么?

最佳答案

拥有较大的User aggregate 不是解决方案,但并不是因为它速度慢且需要优化,而是因为内部字段的内聚性。

为了保护配额限制,用户聚合 只需要上传的文档,仅此而已。这表明您实际上有两个聚合,第二个是 UserDocuments 及其方法 uploadDocument。此方法在内部检查引号不变性。作为优化,您可以保留在 uploadDocument 方法中使用的 int countOfDocumentsUploadedSoFar。这两个聚合仅共享相同的标识(UserId)。

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

关于domain-driven-design - 使用嵌套对象和大集合聚合根优化,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/47811343/

26 4 0
Copyright 2021 - 2024 cfsdn All Rights Reserved 蜀ICP备2022000587号
广告合作:1813099741@qq.com 6ren.com