DDD 聚合性能答案

【问题标题】：DDD aggregate performanceDDD 聚合性能
【发布时间】：2021-06-12 09:41:22
【问题描述】：

我是 DDD 的新手。现在我有一个聚合 Team 和实体 TeamMember：

class Team {
  members: Map<TeamMemberId, TeamMember>;

  add(member) {
    assert(!members.has(member.id), "Team Member is already exists");
    this.members.set(member.id, member);
  }
}

当我执行AddTeamMemberCommand 时，存储库将从MongoDB 加载整个聚合。
当团队很大时，这可能看起来不可接受。

我从 google 和 stackoverflow 中找到了以下内容：

使用 Id 引用而不是实体
延迟加载
重新设计聚合
....

我不确定哪种解决方案适合我，或者对于这种情况是否有更好、更通用的解决方案？ 有我可以查看的 GitHub 示例项目吗？非常感谢。

【问题讨论】：

不确定您从哪里导入了 assert 方法，但我会小心的。这些通常用于测试，并且通常是失败时的程序崩溃。在测试中，这就是你想要的。在你的程序中，没有那么多。
如果是Core java版本的方法，反之亦然。与抛出未经检查的异常不同，不可接受的条件根本不会抛出任何错误。你想要的是两者之间。您希望它抛出可以捕获的异常。考虑一个 try/catch 循环。

标签： domain-driven-design ddd-repositories ddd-service

【解决方案1】：

对于这种情况有更好、更通用的解决方案吗？

对于根本不会更改聚合的读取/查询，延迟加载很好。在 CQRS 的世界中，我们甚至可以完全避免加载聚合，而只是获取我们需要的信息的只读副本。

AGGREGATE 是一组关联对象，我们将其视为一个单元以进行数据更改。

如果我们试图对聚合进行更改，并且想要卸载一堆不必要的信息，这可能意味着我们的聚合边界位于错误的位置，并且我们应该重新设计我们的领域模型，以便加载的信息更符合我们的需要。

例如，如果您尝试只更新 Bob，而不是整个团队，那么这可能暗示 Bob 不是 Team 聚合中的实体，而是属于另一个较小的聚合，跟团队有关系。

Mauro Servienti 的 talk on aggregate boundaries 可能是一个很好的起点。

【讨论】：