hibernate - DDD - 具有大量另一个实体集合的域实体(聚合)

Question

在下面的场景中

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

如果用户数量为 6 位，可以安全地假设直接使用任何 ORM(Java 中的 JPA/Hibernate，可以使用 hibernate 的 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);

现在，您可能会说，诸如“不能具有重复的组成员资格”之类的不变量无法以强一致的方式强制执行，因为不存在围绕所有成员资格具有边界的聚合根。

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

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

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

拥有重复成员(member)资格有哪些风险和影响？可以简单地手动识别和纠正这个问题吗？这条规则最终能否保持一致(自动化过程消除重复)？这种情况真正发生的频率有多少？

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