CODEWITHSUNDEEP
c#domain-driven-design
tlt
tlt

Reputation: 15221

Is it wrong if one Aggregate references other Aggregates Entity?

For example,

public class Company:IAggregateRoot {
  public CompanyId Id;
  public ReadonlyCollection<Office> _offices;
  ...
}

public class EquipmentPiece {
  public EquipmentPieceId Id;
  private CompanyId _companyId;
  private OfficeId _officeId;
  ...
}

So, there is logic that needs to be checked when new Office is being added to the Company and that's done through Company aggregate (as it depends on other properties on Company). On the other hand, each EquipmentPiece has to have a reference to the Office where they are installed.

I want to avoid having the whole tree within a single aggregate (Company.Office.EquipmentPiece).

Is there anything conceptually wrong doing it this way?

Upvotes: 0

Views: 1024

Answers (2)

Yves Reynhout
Yves Reynhout

Reputation: 2990

You're right, referencing by identity is something fairly common. Some objects live as either entities or value objects within the boundaries of a particular aggregate and are referenced by identity in another aggregate. No DDD police will come haunt you :-)

Do consider that you could write something like aCompany.Install(aPieceOfEquipment, atOfficeOfCompany) to help make sure that you're installing equipment at a known company office (at least at the time you're telling). Do consider that this does not match reality: either you express the intent for a piece of equipment to be installed at an office at a certain point in time or you express the fact that a piece of equipment has been installed at an office. Do consider that before a piece of equipment is installed it's still a piece of equipment not yet installed at any office. I'm not implying that the model that you build needs to take this into account - picking the most useful model is the job.

Upvotes: 1

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57249

As described by Evans in 2003, entities in an aggregate may have a reference to the root entity of another aggregate.

In a relational data model, that would normally end up looking like having a foreign key, that would be used to look up the second aggregate root (Office) when reloading the primary (Company).

Today, I would guess you are more likely to see the id of the second root, rather than a reference to the root itself:

public class Company:IAggregateRoot {
  public CompanyId Id;
  public Collection<OfficeId> _offices;
  ...
}

Upvotes: 1

Related Questions