到目前为止，我一直在阅读这方面的内容，我认为这只是一个设计决定，但不幸的是，我无法弄清楚哪种方法是最好的。
我有很多实体，其中有应用程序、用户、角色和权限。有如下一些规则，
- 一个应用程序必须至少有一个用户。
- 一位用户必须至少在一个应用程序中。
- 每个用户在其所属的每个应用程序中都有不同的角色、密码和其他属性。
- 每个角色有不同的权限，等等。
我的问题是我应该如何构建每个聚合？，我的方法如下:
我的第一个方法是为应用程序、用户、角色等创建一个聚合。但是我是否应该为应用程序和用户之间的多对多关系创建一个不同的聚合，因为它将具有附加属性？或者我应该将多对多关系转换为一对多关系吗？如果是这样，我该如何实现？
第二个是只为应用程序创建一个聚合，并将用户添加为 ChildEntity，但我不确定它是否适用于给定的上下文，如果是这样，我是否应该将角色和权限实体作为ChildEnties 也在我的应用程序聚合中吗？
请让我知道您对此的想法，如果有另一种观点可以帮助我，那就太好了。谢谢你的建议。
最佳答案
老实说，这些规则看起来很人为。如果您绝对需要所有这些方面的强一致性，那么您需要一个巨大的 ApplicationAccess 聚合，这肯定会非常繁忙，因为给定应用程序的任何访问权限更改都会与同一应用程序的任何其他更改发生冲突。
这个巨大的 AR 本身甚至不足以涵盖“一个用户必须至少在一个应用程序中”。这意味着您可能必须在每个角色成员添加/删除时更新 User AR 和 ApplicationAccess AR。
例如
// 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 中并且可能对规则。
关于many-to-many - 在 DDD 中处理多对多关系，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/68367649/