DDD - 域实体（聚合）与另一个实体的大量集合

Question

在下面的场景中

class Group {
    ...
    Set<User> users;
    ...
}

其中用户数为 6 位，可以安全地假设直接使用任何 ORM 对集合执行任何操作都是低效的（JPA/Hibernate in Java，可能是与休眠的 ExtraLazyCollection 一起工作）。

为了处理这种情况，是否可以将聚合和组合实体之间的域关系表示为集合，而不是将其表示为由 DomainService 支持并随后由存储库支持的操作。

class Group {

   User addUser(User anUser, GroupUserService aGroupUserService){ ... }
   void removeUser(User anUser, GroupUserService aGroupUserService){ ... } 
}

class GroupUserService {

   GroupRepository  groupRepository;

   User addUser(User anUser) {
       groupRepository.addUser(anUser);
   }
}

class GroupRepository {

    User addUser(User anUser) {
      //execute the query(JQL or native) to save the user 
    }
}

在不违反 DDD 原则的情况下，这听起来像是一个合理的解决方案吗？在这种情况下是否存在被忽视的优化。

Answer 1

看来你可能漏掉了GroupMember的概念。

GroupMember member = group.addUser(user);
groupMemberRepository.add(member);

现在，您可能会说 "you cannot have duplicate group memberships" 等不变量不能以强一致的方式强制执行，因为不存在围绕所有成员资格的边界的聚合根。

虽然业务规则确实不能在域中强制执行，但您可以简单地依赖数据库中的唯一约束（假设存储机制支持它们）。

这是我们可以做出的妥协，以便保持高度一致并保持实用性，而不是成为一个纯粹主义者。

但是，还有另一种选择，但需要进行深入的业务分析。我们往往倾向于将业务规则视为数学模型，但现实生活往往不能这样建模。

拥有重复会员资格有哪些风险和影响？这可以简单地手动识别和更正吗？能否使这条规则最终保持一致（自动化过程消除重复项）？这种情况多久发生一次？

我相信这些是您需要回答的问题，您通常会意识到业务通常比您想象的更灵活，最终一致性通常是一个可行的解决方案。

DDD - 域实体（聚合）与另一个实体的大量集合

DDD - Domain entity(aggreagate) with large collection of another entity

domain-driven-design

hibernate

jpa