DDD 综合性能
DDD aggregate performance
我是 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 和 Whosebug 中找到了以下内容:
- 使用 Id 引用而不是实体
- 延迟加载
- 重新设计聚合
- .....
我不确定哪种解决方案适合我,或者对于这种情况是否有更好、更通用的解决方案?是否有 GitHub 示例项目我可以看看吗?
非常感谢。
is there a better, more generic solution for this scenario?
对于 reads/queries,您根本不会更改聚合,延迟加载很好。在 CQRS 的世界里,我们甚至可以完全避免加载聚合,而只是获取我们需要的信息的只读副本。
An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.
如果我们试图对聚合进行更改,并且很想不加载一堆不必要的信息,那么可能意味着我们的聚合边界在错误的地方,我们应该重新设计我们的域模型,以便加载的信息更符合我们的需要。
例如,如果您尝试只更新 Bob,而不是整个团队,那么这可能暗示 Bob 不是 Team 聚合内部的实体,而是属于一个不同的、更小的实体聚合,跟团队有一定关系。
Mauro Servienti 的 talk on aggregate boundaries 可能是一个很好的起点。
我是 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 和 Whosebug 中找到了以下内容:
- 使用 Id 引用而不是实体
- 延迟加载
- 重新设计聚合
- .....
我不确定哪种解决方案适合我,或者对于这种情况是否有更好、更通用的解决方案?是否有 GitHub 示例项目我可以看看吗? 非常感谢。
is there a better, more generic solution for this scenario?
对于 reads/queries,您根本不会更改聚合,延迟加载很好。在 CQRS 的世界里,我们甚至可以完全避免加载聚合,而只是获取我们需要的信息的只读副本。
An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.
如果我们试图对聚合进行更改,并且很想不加载一堆不必要的信息,那么可能意味着我们的聚合边界在错误的地方,我们应该重新设计我们的域模型,以便加载的信息更符合我们的需要。
例如,如果您尝试只更新 Bob,而不是整个团队,那么这可能暗示 Bob 不是 Team 聚合内部的实体,而是属于一个不同的、更小的实体聚合,跟团队有一定关系。
Mauro Servienti 的 talk on aggregate boundaries 可能是一个很好的起点。