到目前为止，我一直在读这篇文章，我认为这只是一个设计决定，但不幸的是，我不知道哪种方法是最好的。
我有许多实体，其中包括应用程序、用户、角色和权限。有以下一些规则
- 应用程序必须至少有一个用户
- 用户必须至少在一个应用程序中
- 每个用户在其所属的每个应用程序中都有不同的角色、密码和其他属性
- 每个角色都有不同的权限，依此类推
我的问题是我应该如何构建每个聚合？，我的方法如下：
-
我的第一种方法是为应用程序、用户、角色等创建一个聚合。但我是否应该为应用程序和用户之间的多对多关系创建一个不同的聚合，因为它将具有不同的聚合属性？，还是应该将多对多关系转换为一对多关系？，如果是这样，我该如何实现呢？
-
第二个是只为应用程序创建一个聚合，并将用户添加为子实体，但我不确定它是否适用于给定的上下文，如果适用，我的应用程序聚合中是否也应该将角色和权限实体作为子实体？
请让我知道你对此的看法，如果有其他观点可以帮助我，那就太好了。谢谢你的建议。
老实说，这些规则看起来相当人为。如果您绝对需要所有这些方面的强一致性，那么您需要一个巨大的ApplicationAccess聚合，它肯定会非常繁忙，因为给定应用程序的任何访问权限更改都会与同一应用程序的其他更改相冲突。
这个巨大的AR本身甚至不足以覆盖"；用户必须至少在一个应用程序中"规则，这意味着您可能必须在每次添加/删除角色成员时更新UserAR和ApplicationAccessAR。
例如
// Assume transactional
function removeUserFromRole(userId, applicationId, roleId) {
applicationAccess = applicationAccessRepo.existingOfId(applicationId);
user = userRepo.existingOfId(userId);
applicationAccess.removeUserRole(user, roleId);
user.trackRoleRemoved(); // decrement and throws if 0 (trackRoleAdded would increment)
}
就像你可以猜到的那样，这个设计似乎不是很可扩展。它可能适用于少量用户，而不需要太多的并发访问修改，但在其他方面可能是错误的设计。如果你选择它，你可能会想使用悲观锁定，而不是乐观+重试。
如果你想要一个更有效的模式，我认为你别无选择，只能探索放松规则的可能性，让它们最终保持一致，而不是强烈一致。
例如，为什么User没有访问权限这么重要？你能运行异常报告来列出这些吗？你能标记User吗？这样他们的访问权限就需要手动更新了？
这同样适用于所有其他规则，并且有无限的可能性来处理最终的一致性。如果发现某些操作违反了某些规则或只是标记&具有如上所述的手动分辨率等。
无论如何，质疑规则的一个好方法是分析"；成本；通过并发修改违反规则的频率，以及如果您将事物放在不同的AR中并对规则进行可能过时的检查，在预期的并发使用下这种情况可能发生的频率。