Many to Many relations between Aggregates

[nilaxann65]

I'm working on a SaaS project, and I have the following root aggregates:

export class Person {}

and

export class Company {}

How can I create a relation between these two aggregates? I know that I must use an object value. In the case of a Person:

export class Memberships {
  companyId: string;
  role: string;
}

And in the case of a Company:

export class Members {
  memberId: string;
  role: string;
}

These value objects have the same properties, but I'm repeating code. How can I centralize or improve this code? I'm considering this because I'm working with TypeORM, and at the database level, these value objects represent a unique table.

[Sairyss]

Similar to this discussion: #132

Solution depends on your use case.

Do you need to have members in a company? Most likely yes, so keep it there.

export class Company {
  members: Member[] 
}

Do you need companies in a Person aggregate? are you using it in some way? if not, there is no need for a relation there. If yes, you can keep a list of company IDs in a Person.

export class Person {
  // ...
  companyIds: string[]
}

To get a role you can load a company and get a role from there, instead of keeping role in two places.

Personally I would not put companies into a Person aggregate, there is no need for it to know about companies in most cases, you have Company aggregate for keeping that info and doing operations on it.
Having relations in the database doesn't necessarily mean you also need those relations on an aggregate level.

[nilaxann65]

You're right, the only reason I was interested in having an array of companies in the personAggregate was to list companies belonging to the same person. But now that I see it this way, if I query from the person aggregate, I would only get the company IDs, and a second request would be necessary to obtain the company data. It would be much more efficient to maintain this logic from the company aggregate, where the necessary data is available.
I still have to get rid of the mindset that relationships at the database level are not the same as in the domain hahaha.

Thanks!

[Sairyss]

the only reason I was interested in having an array of companies in the personAggregate was to list companies belonging to the same person

If you want this listing only for queries in the read model, there is no need for the aggregate at all, you can execute a single database query with a join person+companies and you're done, no aggregate in the middle.
Aggregates are mostly valuable for write model, when you need to check some invariant and save the new state.

[nilaxann65]

I understand that i can query a join person+company, but supossing Im working on the person module, when mapping the result on the repository, what type should i map into? should i have a value-object|entity copy from the company entity with the necesary fields? could I use the props from company from the company module?

[Sairyss]

a join person+company, but supossing Im working on the person module

You can create a separate read module and separate it from writes to avoid mixing different aggregates together (CQRS)

when mapping the result on the repository

Repository is a pattern for retrieving domain aggregates. For queries you don't need any repositories, just retrieve it directly.

what type should i map into?

You map to a DTO class/interface that you create specifically for that query.

Example find-users.query-handler.ts