domain-driven-design - 如何处理resolvejs中聚合根之间的关系

Question

我无法弄清楚如何处理一些关于resolvejs中聚合根之间关系的基本内容。基本问题是我如何处理关系的完整性？为此，您似乎需要同时了解双方的知识，但在写入方面似乎不允许这样做。

下面是设置：我正在尝试构建一个用户管理工具，并且我有两个聚合根，User并且Organisation. 我需要允许两者独立存在并定义它们之间的access关系（即用户可以访问任意数量的组织）。

如果关系属于User，我可以创建一个创建命令，例如grantAccessToOrganisation在User聚合上接受 an organisationId，但这会引发几个问题。我如何确保organisationId提供的是真实的？似乎它需要在命令处理程序中发生，但由于命令属于User聚合，我无权访问Organisation聚合。另外，当组织被删除时，我应该如何处理？似乎这应该对所有有权访问它的用户产生副作用，但我似乎没有在写入端进行查询的好方法。

标签： domain-driven-designrelationshipevent-sourcingresolvejs

Answer 1

尽量不要将聚合视为传统系统中的“实体”。选择聚合根作为事务和一致性边界。

这意味着给定聚合的所有命令都是连续的，它的状态是一致的，这意味着您可以确保您的命令应用于预期的聚合状态，并且其他用户或进程没有进行任何更改。

作为一个极端的例子，你甚至可以有一个单一的聚合“系统”，你可以访问整个系统状态。但这意味着状态的大小将是巨大的，每个命令都会锁定整个系统。

所以选择你的聚合足够大以控制它的交易并且足够小以不阻塞其他交易。

在您的示例中，我可以猜测 User 更多的是关于身份、登录名、个人资料、头像 - 诸如此类。它可以在没有组织知识和访问权限的情况下生存。组织是处理访问权限的集合体，而更改访问权限是影响单个组织的事务。

因此，我会将grantAccess 命令发送给组织，而不是您示例中的用户。但当然这取决于其他要求，我在这里可能是错的。

此外，总会有一些可以用 saga 实现的聚合间业务规则。例如，如果禁用用户登录，则其访问权限将在 30 天后删除。Saga 是一个长期运行的业务事务，可以影响多个聚合。