CODEWITHSUNDEEP
referencetransactionsdomain-driven-designentityaggregate
David Rettenbacher
David Rettenbacher

Reputation: 5120

DDD: Reference another aggregates child entity

I currently digging into DDD and need a little enlightment.

I have two entities

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

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:

Lg
warappa

Upvotes: 10

Views: 2494

Answers (2)

David Rettenbacher
David Rettenbacher

Reputation: 5120

The violated rules and MikeSW's question about behaviour in 'real world' made me rethink my approach. After a talk with the domain expert I realised that my approach didn't match the domain, therefore violating ddd. I'm currently redesigning my models.

@Question: If I left the TempleVariants in the Temple model, I would have gone with the "identity-relative-to-its-parent" approach to have a posibility to reference a variant (as MattDavey suggested). But the more important error in design would still be present.

If the basic design would have been right, I would have made both separate aggregate roots. It would have worked (from my perspective) but again it would have covered a desing error (at least in my case).

Generally, I think, if ddd rules are violated, it's good to take a step back, review the actual business and check wheater what you've got really matches you domain - or not.

Thank you for your help!

Upvotes: 0

Giacomo Tesio
Giacomo Tesio

Reputation: 7210

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.

Upvotes: 4

Related Questions