Domain Driven Design - Aggregate Roots

Question

I'm struggling with aggregates and aggregate roots. I have a natural aggregate root which works for about 60% of the user requests. I.e. those requests naturally apply to the aggregate root.

Within my aggregate I have another entity which can only exist as a member of the aggregate root. Users, however, will be told about this other entity object. It will sometimes make sense, conceptually, for users to operate on this non-aggregate root object directly.

So, I think I have a couple of options:

1. They can they both be aggregate roots depending on which operation is being requested by the user.
2. All operations have to go through the top level aggregate root.

Note that the top level aggregate root will hold a collection of this other entity.

---

Example:

Main aggregate root: Car

Second entity: Seat (a Car has either 2 or 4 seats depending on type). In my domain seats can only exist as part of a car.

Most operations in the domain are at the Car level. So that will be a good candidate for aggregate root. However, (and I'm struggling for examples here), some operations will be at the seat level, e.g. SpillCoffee, ChangeFabric, Clean....

Can Seat and Car both be aggregate roots? Or should I always start with Car?

Thanks

Answer 1

The idea of an aggregate is to guarantee consistency, being the root responsible for data integrity and forcing invariants.

Suppose there's a rule like "The fabric of all seats must be the same", or ""you can only spill coffee on the seat if there's someone inside the car". It will be much harder to enforce these, once the clients will be able to change the fabric separately, or these invariants will need to be forced outside (danger zone).

IMHO, if integrity or forcing invariants is not an issue, then aggregates are not really needed. But, if it is necessary, my advice is to start everything with the car. But always think of the model. If there are invariants like these, then who enforces these invariants? Then try passing this idea to the code, and everything should be fine.

Answer 2

In the case of a shopping cart with an cart and line items I have both of those as aggregate roots since I often modify them independently.

public class Cart : IAggregateRoot
{
  public List<LineItem> LineItems {get;}
}

public class LineItems : IAggregateRoot
{
  public List<LineItem> LineItems {get;}
}

However, I have a separate bounded context for orders and in this case I only need to have one aggregate root since I no longer need to modify the line items independently.

public class Order : IAggregateRoot
{
  public List<LineItem> LineItems {get;}
}

The other option is to have a way of looking up the aggregate root from a child ID.

Car GetCarFromSeatID(guid seatID)

Answer 3

Probably you need some deeper knowledge of some aspect of the domain model. This question shows that you are about to invent a way to organize the entities to supply the system, when, ideally, this kind of questions are already answered before implementation.

When this pops out only on the system implementation, you whether go back to review the domain or you discovered some fragility whose feedback could - and should - aggregate changes on related details of the business to make the domain richer and better modeled.

In the car example, I used the approach of two aggregates who correlate different contexts. The first would be the "car has a seat" approach, and in this aggregate the possible actions for "seat" would be just the ones that make sense to "seat as part of a car". Example: Clean.

The second aggregate would be in the context of "seat", and there would be the possible actions and configurations for seat as a standalone. Example: ChangeFabric, ColorList. This way, the aggregate "car" has "seat", but the clients can know seat on the context that makes sense. Which is dangerous, like said by samuelcarrijo on previous post. If the modifications between contexts affects the domain integrity, you lost all the aggregate concept.