domain-driven-design - DDD 总体性能

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

我是 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加载整个聚合。
当团队规模很大时,这可能看起来 Not Acceptable

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

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

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

最佳答案

is there a better, more generic solution for this scenario?

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


An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.

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

例如,如果您尝试仅更新 Bob,而不是整个团队,那么这可能暗示 Bob 不是团队聚合内的实体,而是属于不同的较小聚合,这和团队有一定的关系。

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

关于domain-driven-design - DDD 总体性能,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/67947557/

相关文章:

domain-driven-design - 领域驱动设计 : Avoiding anemic domains and modelling real world roles

domain-driven-design - 对应用程序结构和通信方向的疑问

linq-to-sql - 如何使 POCO 在 DDD 中与具有复杂关系的 Linq-to-SQL 一起工作

c# - 如何确定为接口(interface)的不同实现调用哪个存储库?

domain-driven-design - 前端与ddd微服务后端的业务逻辑重复

java - Java 的全栈框架

c# - 在 DDD 的哪一层将类声明为聚合根?

asp.net-mvc-3 - MVC-3 项目结构

domain-driven-design - 用 DDD 连接点

domain-driven-design - DDD、外部数据和存储库