Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

DDD: Reference another aggregates child entity

I currently digging into DDD and need a little enlightment.

I have two entities

  • Temple
  • TempleVariant

Temple (earpiece) contains the base information (name, description,...) and has n variants which have technical descriptions (CAD-drawing, size,...)

My first impression was: Temple and TempleVariant form an aggregate - they belong together: They seem very tightly coupled

  • if I delete a Temple all TempleVariants should be deleted likewise
  • TempleVariants cannot exist without Temple (at least it makes no sense)

But then I read that nothing outside the aggregate root is allowed to reference an entity inside another aggregate. But actually not Temple is referenced by outside entities but the TempleVariants.

Does this mean that in (DDD) reality Temple and TempleVariant are different aggregates which just seem to be an aggregate?

But then, what if I delete Temple? As I said TempleVariants must also be deleted. But that would then violate the rule "One aggregate-change - one transaction" (or what it is called :)) because my "feeling" is that I would have to delete them in one transaction...

So my questions are:

  • are those two aggregates?
  • if so: how to handle deletes?

Lg
warappa

like image 910
David Rettenbacher Avatar asked Apr 15 '13 08:04

David Rettenbacher


People also ask

Can an aggregate reference another aggregate?

[Evans] states that one Aggregate may hold references to the Root of other Aggregates. However, we must keep in mind that this does not place the referenced Aggregate inside the consistency boundary of the one referencing it. The reference does not cause the formation of just one whole Aggregate.

Can aggregates share entities?

As you rightly pointed out, Entity instances shouldn't be shared between aggregates, as one aggregate wouldn't be aware of changes to the entity made through another aggregate and couldn't enforce its invariants.

Can a bounded context have multiple aggregates?

Aggregates. The stategic DDD's bounded contexts typically contain multiple aggregates. Within the aggregates, you can model your system with the tactic DDD patterns, such as Entity, Value Object, Domain Event, Service and Repository.

How is aggregate DDD defined?

Aggregate is a pattern in Domain-Driven Design. A DDD aggregate is a cluster of domain objects that can be treated as a single unit. An example may be an order and its line-items, these will be separate objects, but it's useful to treat the order (together with its line items) as a single aggregate.


1 Answers

Each class in the domain model should map the ubiquitous language that you learn from a domain expert. This look a quite interesting domain, btw.

To me, there are two distict path to cope with your concerns.

You should remember that aggregates are required to ensure business invariants. That is: they recieve commands that change their state and they are responsible to avoid invalid operation (through proper exceptions). More often than not they are entities since they hold an identity.

TempleVariants as Value Objects

If (and only if) the instances of TempleVariant are required to handle business rules, they should be part of the aggregate. That is, the Temple contains them.
However they should be immutable objects: only the Temple can recieve commands that change its state (always as a whole).

In this case when you delete a Temple, all the connected TempleVariants disappear. Still, in most of DDD applications that I have developed, no entity gets deleted: they are just archived. But I'm used to financial applications and domains, may be that in your domain deleting temples is the right thing to do.

TempleVariants as DTOs

If no command in the Temple requires any TempleVariant to ensure business rules, the letter are probably just useful descriptive data that can be handled with proper DTOs mapping the DB schema. In this case, I would define an infrastructural services that returns all the variants for a specified Temple.

In this case you could expose the shared identifier of the related Temple in the DTOs but it's not required.

For further informations on aggregate design I strongly suggest you to read the Vernon's essays on aggregate design.

like image 199
Giacomo Tesio Avatar answered Sep 27 '22 23:09

Giacomo Tesio