How to model 1 to many relationships in DDD (Domain Driven Design)

Question

I think I am struggling to model a relationship between 2 entities. I am trying to do so in a way that promotes DDD and captures business semantics. The following is my business context:

I am developing a memberships microservice. It is a service that is used to create organizations to which you can then invite members. An organization can have varying amounts of members throughout its lifecycle but needs to have at least one at all times.

So I have thought of multiple ways of trying to model this and am not sure which one is best and why.

Option 1: Making the Organization an Aggregate Root

class Organization {
  private id: OrgID;
  private name: Name;
  private members: Members[];

  constructor(initialMembers: Member[], name: Name, id: OrgId) {
    if(initialMembers.length < 1) {
     throw new Error("At least one member is needed");
    }
    this.members = members;
    this.name = name;
    this.id = id;
  }

  create

  addMember(member: Member){
   //..
  }
  removeMember(id: MemberID) {
   //..
   if (this.members.length === 1) {
     throw new Error("At least one member is needed");
   }
  }
}

Pros: Members are a concept that only exist within the context of an organization. The organization effectively acts as the aggregate root and enforces an invariant (Organization needs at least 1 member).

Concern: having an array of all members represented in this model is technically accurate but im afraid that I would not be able to hold all member sub entities in memory in the case I have a lot of them.

Option 2: Member has reference to org + injecting a repository to the Organization

interface Member {
  organizationId: OrgId;
  ...
}

class Organization {
  private id: OrgID;
  private name: Name;
  private memberRepo: MemberRepo;

  constructor(memberRepo: MemberRepo, name: Name, id: OrgID) {
    this.memberRepo = memberRepo;
    this.name = name;
    this.id = id;
  }

  addMember(memberName: string){
   const member = new Member(this.orgId, memberName);
   this.memberRepo.add(member)
  }
  
  removeMember(id: MemberID) {
   const numberOfMembers = memberRepo.sizeByOrg(this.orgId);
   if (this.members.length === 1) {
     throw new Error("organization should have at least one member");
   } else {
     //...
   }
  }
}

pros: This method is guaranteed to not exhaust application memory in the case where there is a lot of members in an organization.

concerns: I keep reading that I shouldn't pass a repository to an entity. I am still unsure whether this concern is warranted or not in this situation since I am only referencing a Repository interface here. The interface is technically part of the domain. But im not sure if passing the entire repo is overkill or not.

Option 3: Create a domain service that represents the interaction/relationship between organizations and members

class Organization {
  private id: OrgID;
  private name: Name;
  private orgMemberService: OrgMemberService[];

  constructor(orgMemberService: OrgMemberService, name: Name, id: OrgId) {
    this.orgMemberService = orgMemberService
    this.name = name;
    this.id = id;
  }

  addMember(member: Member){
   this.orgMemberService(this.id, member);
  }

  removeMember(memberId: MemberID) {
   this.orgMemberService(this.id, memberId);
  }
}

Pros: This better abides the by the Single Responsibility Principle as the relationship between an org and its members is cleanly encapsulated by the service.

Concerns: Similar to the situation above, this passes a whole class instance to the constructor to instantiate the Organization. The OrgMemberService would still be dependent on the repo interface.

Option 4: Add members to organization outside of Organization class

class Organization {
  private id: OrgID;
  private name: Name;

  constructor(name: Name, id: OrgId) {
    this.name = name;
    this.id = id;
  }
}

and then in a service

class OrgMemberService {
 private organization: Organization;

 constructor(organization: Organization) {
  this.organization = organization
 }

 addMember() {}
 removeMember() {}
}

Pros: The instantiation is much simpler and no heavy singleton business logic service is passed to the constructor.

Cons: The model has become rather anemic which is something we are typically advised against. In addition, the Organization class no longer responsible for the feasibility of its own existence as another service is now responsible for ensuring that at least 1 member exists.

Your input is very much appreciate here.

Answer 1

Organisations have typically different kind of memberships, the typology being generally laid down in the organisation’s bylaws:

• This implies that conceptually, the membership makes only sense in relation to the organization.
• Moreover, some invariants of the organization may involve membership. In some countries for example, legal associations (sport clubs etc) must have a minimum number of members.

In this regard, option 1 seems the most appropriate, if the members are understood as memberships (i.e. only the “belonging” of a person/entity to that organization and not this person/entity itself).

The entities (persons, companies, organizations), that can become member should not be part of the organization aggregate, because they exist independently of the organisation and could have a membership in several organizations. They form an independent aggregate.

The relation between the two aggregates (organization+memberships on one side, the people on the other) could be managed by a domain service (option 3).

Answer 2

It’s a best practice that Aggregates only reference other aggregates by Id.

Assuming Member is also an AggregateRoot, including a collection of MemberId in Organization will allow you to enforce the business rule that every organization should have at least one member, without having to load all members into memory.

Answer 3

Option 2: Member has reference to org + injecting a repository to the Organization

The second step does not follow from the first.

If members are their own aggregate root, which I do agree is the right approach here due to not wanting to load all the members all the time (and what I suspect to be a heavier feature set on the members themselves), then they represent their own bounded context. Therefore, the members bounded context handles its own CRUD logic. Another bounded context (organisation) does not handle it for them, as that would directly contradict the independent nature of a bounded context.

Semantically rephrasing your approach, you don't then "add a member to the organisation", but you create a member (and fill in their organisation ID as part of the data). You don't "remove a member from an organisation", you delete the member (which inherently removes any reference they made to their organisation).

Do take note that how you model your domain does not necessarily reflect what your UI looks like. It's perfectly possible to create a single "organisation" web page which lists all of its members and allow you to add/remove them. To the end user, this looks like a single source of information, even though the backend logic actually relies on two separate bounded contexts to provide all of the data/functionality to the end user.

An organization can have varying amounts of members throughout its lifecycle but needs to have at least one at all times.

This can be handled on the service level instead of the domain level; by only exposing the "organisation create" logic in a way that includes the organisation's first member; and similarly for the "member delete" logic to validate that this is not the only member of the organisation (or to then also delete the organisation if it is the case).

Answer 4

In your specific use case, I would add a property called memberCount to Organization aggregate and use it to validate if you have at least one member in the organization when adding and removing them.

You also mentioned you don't want to keep a list of members in memory, so I would modify the addMember method to return a Member instance. In this case, your organization class becomes also a Factory of members.

Example:

interface Member {
    organizationId: OrgId;
    ...
}    

class Organization {
    private id: OrgID;
    private name: Name;
    private memberCount: int;
  
    constructor(name: Name, id: OrgID) {
      this.name = name;
      this.id = id;
    }
  
    addMember(memberName: string) : Member {
     const member = new Member(this.orgId, memberName);
     memberCount+=1;
     return member;
    }
    
    removeMember(member: Member) {
     if(member.organizationId !== this.id)
       throw new Error("Member is not part of the organization");

     if (this.memberCount === 1) {
       throw new Error("organization should have at least one member");

     this.memberCount-=1;
    }
  }

The responsibility of saving the members would be then delegated to an application service.

Example:

class OrgMemberService {
    private orgRepo: OrgRepo;
    private memberRepo: MemberRepo;
   
    constructor(orgRepo: OrgRepo, memberRepo: MemberRepo) {
        this.orgRepo: orgRepo;
        this.memberRepo = memberRepo;
    }
   
    addMember(orgId: OrgID, memberName: string) {
        org: Organization = this.orgRepo.findById(orgId);
        member: Member = org.addMember(memberName);
        
        this.orgRepo.save(org);
        this.memberRepo.save(member);
    }

    removeMember() {
        ....
    }
   }

To guarantee that the memberCount won't be modified by multiple different users at the same time, you can use optimistic locking or in the worst case scenario, pessimistic locking.