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
Temple
all TempleVariant
s should be deleted likewise
TempleVariant
s 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 TempleVariant
s 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...
Lg
warappa
[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.
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.
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.
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.
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.
TempleVariant
s 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.
TempleVariant
s 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With