CODEWITHSUNDEEP
domain-driven-designaggregateroot
Jesse
Jesse

Reputation: 562

DDD Aggregates vs Entities

What to do with an object that has two dependencies:

Let's say we have three objects: client, company and a contract. Contract needs a client and a company to exist.

Naturally, business wise, the contract belongs more to the client than it does to the company, however the companies provides the contract to the client.

For now, I have all three as a separate aggregate root. Because you should be able to quickly query the existing contracts for a specific company as well. If contract would be an entity under the client aggregate root, I'd need to query all the clients which have a contract of X company and then return a flattened list of those contracts. Which seemed a bit odd?

Secondly, contract itself has a lot of entities, with more entities below them.

To explain the hierarchy in a simple way:

Contract aggregates contains a list of entity A, entity A has multiple items of entity B and entity B has multiple items of entity C. So it's a deep structure, which all have to be exposed through the aggregate above it.

If I'd put the contract aggregate root as an entity below client, my client aggregate needs to carry all those extra methods for what's below contract as well. And soon I'll end up with almost everything under the same aggregate.

So my question is: what questions can I ask myself to answer this kind of issue? There's probably no right or wrong, but there should be some guidelines on how to deal with an issue like this?

Thanks!

Upvotes: 0

Views: 1672

Answers (1)

VoiceOfUnreason
VoiceOfUnreason

Reputation: 57204

what questions can I ask myself to answer this kind of issue?

Here is how Eric Evans defined AGGREGATE

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

"Change" is the important idea here; in designing our aggregate boundaries, we don't particularly care about data that appears in the same report (read-only view), we care instead about what data needs be to considered when making changes.

See also Mauro Servienti: All our aggregates are wrong.

Upvotes: 1

Related Questions