我有以下 DDD 场景，分为以下聚合:
用户，
friend (用户协会)，
文件(供用户上传)，
图库(文件分组)，
消息(用户通信)，
群组(用户可以创建，其他成员可以加入)，
GroupMessages(发送给群组所有成员的消息)，
GroupForums(群成员可以讨论各种话题)
这就是令人困惑的地方。用户与 GroupForums 的所有内容相关联。必须通过用户存储库访问其他聚合似乎不合逻辑，但从级联的角度来看，如果我删除了用户，从技术上讲，与用户关联的记录也应该消失。
似乎我也不应该将此处存在的所有一对多关联添加到用户实体，因为从数据库中提取数据似乎很荒谬，尤其是当我尝试提取与用户关联的每条记录时.组织聚合和存储库的推荐策略是什么，以及处理给定实体的大量一对多关系的正确方法是什么？
最佳答案
您在“用户与一切相关联……”这句话中使用了“关联”一词，这是一个很好的线索。将聚合根关联起来，甚至一个“属于”另一个聚合根，都是绝对好的。但是，您需要查看一个实体是否可以在没有 AR 的情况下存在。如果可以的话，它可能有自己的生命周期，应该是一个 AR。如果不能，则它是聚合的一部分。这可能很难提取。
您的 AR 需要有非常清晰的界限。例如，即使论坛可能需要用户创建它，但这并不意味着论坛需要(甚至可以)在删除用户时被删除。因此，论坛中的用户可能会变成仅包含用户名和 ID 的 ForumCreator(一个值对象)。删除用户后，论坛可以继续存在。
在 Order/OrderLine/Product 场景中，如果您选择删除包含特定产品的所有订单行，则删除它没有多大意义。我知道一个产品可能永远不应该被删除，但我们将以它为例。您只需将相关产品数据“非规范化”到订单行中，例如:产品 ID、产品名称。因此，即使产品名称发生变化，也不意味着所有订单行都需要更新，甚至应该更新。事实上，订单行代表了一个时间点，应该保留“原始”的产品名称。购买者可能订购了“Some lirril product”，然后将名称更改为“Little product”。虽然是完全相同的产品，但不是一回事。购买者只记得原件。
我希望这是有道理的，并在某种程度上有所帮助。您肯定需要找到对象图中的那些硬边才能获得真正的聚合。
关于c# - DDD : one-to-many relationship between user aggregate root and almost all entities in other aggregates，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/16378688/