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

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);

现在,您可能会说不能以强烈一致的方式强制执行诸如"您不能拥有重复的组成员资格"之类的不变量,因为没有聚合根在所有成员资格周围具有边界.

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

这是我们可以做出的妥协,以便保持一致并保持实际而不是纯粹主义者.

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

拥有重复会员资格有哪些风险和影响？这可以简单地手动识别和纠正吗？这条规则最终能否保持一致(自动化流程可以摆脱重复)？这经常发生多少次？

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