Question

I have been using DDD for a while know so I am comfortable with the idea of aggregates. At first I did have troubles wrapping my head around not using/persisting references to other root aggregates but I think I’m on board… so:

• Storing a root aggregate as a one document…. check
• Using denormalized references containing properties that do not change or rarely change…. check

For the times that I DO want to have a full reference to another root aggregate, I understand it is recommended that I persist a reference to its ID and can use the RavenDB client API’s Includes to retrieve all the entities efficiently.

That handles the data part, what I haven’t seen is the best way to handle this in my entity class:

1. Have both Product and ProductId properties in my class using [JsonIgnore] on the Product to ensure it doesn’t get persisted with the document.
   • The full object graph could then be glued back together in the repository (using API’s Includes for efficiency) or I could inject a service into the entity that would fetch Product lazily (possible N+1 hit)
2. Glue it back together in a ViewModel. I don’t like this idea as I could end up with an unexpected NULL reference in the domain if not used correctly.
3. Some other obvious way that I’m not seeing?

Thoughts?

Answer 1

In DDD there are at least two valid points of view. Some ppl link root aggregates only by ID or another valid key and second is using platform specific references to other objects. Both has it’s own pros and cons.

With NoSql solutions like RavenDb, it’s probably better to use first approach, because second is just technically wrong.