Search code examples
domain-driven-designddd-repositoriesddd-service

DDD aggregate performance


I'm new to DDD. Now I've an aggregate Team and entities 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);
  }
}

When I execute AddTeamMemberCommand, the repository will load the entire aggregate from MongoDB.
when the team is large, this may seem unacceptable.

I found the following from google and stackoverflow:

  • Use Id references instead of entities
  • Lazy load
  • Redesign aggregation
  • ....

I'm not sure which solution is right for me, or is there a better, more generic solution for this scenario? Is there a GitHub sample project i can look at? Thank you very much.


Solution

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

    For reads/queries, where you aren't going to be changing the aggregate at all, lazy loading is fine. In the world of CQRS, we might even avoid loading the aggregate altogether, instead just fetching a read-only copy of the information that we need.


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

    If we're trying to make a change to an aggregate, and are tempted to leave a bunch of unnecessary information unloaded, that may imply that our aggregate boundaries are in the wrong places, and that we should be re-designing our domain model so that the loaded information better fits with what we need.

    For example, if you are trying to update just Bob, not the entire team, then that may be a hint that Bob isn't an entity inside of the Team aggregate, but is instead belongs in a different, smaller aggregate, which has some relationship with team.

    Mauro Servienti's talk on aggregate boundaries may be a good starting point.