Skip to main content
Software Engineering

Return to Question

Notice removed Draw attention by CommunityBot
Bounty Ended with no winning answer by CommunityBot
Tweeted twitter.com/StackSoftEng/status/1428371191182594050
Notice added Draw attention by Doc Brown
Bounty Started worth 50 reputation by Doc Brown
I did your job, removed the "list of examples" and added some references
Source Link
Doc Brown
Doc Brown
  • 214k
  • 34
  • 394
  • 603

In the context of a web application where we handle only one command per request in a stateless fashion, could somebody point me to concrete examples of things that could go wrong if we do notwe always have to load/save aggregates as one atomic unit? Why do we insist onis it recommended not to partially load/save aggregates? What are the fundamental reasons behind this rule of thumb?

Some references where I found this recommendation (but no real explanation why):

DDD: do I really need to load all objects in an aggregate?

How to work with large aggregate roots?

I could only think of caching but I think there is more. Maybe inconsistency by concurrent writers?

Notes: I have read Eric's blue book up to the end of Aggregates chapter, iterated over most of the questions in SE and SO about aggregate persistence, and watched a few DDD courses on Pluralsight, but I could not find a direct and detailed answer.

Thank you

In the context of a web application where we handle only one command per request in a stateless fashion, could somebody point me to concrete examples of things that could go wrong if we do not load/save aggregates as one atomic unit? Why do we insist on not to partially load/save aggregates? What are the fundamental reasons behind this rule of thumb?

I could only think of caching but I think there is more. Maybe inconsistency by concurrent writers?

Notes: I have read Eric's blue book up to the end of Aggregates chapter, iterated over most of the questions in SE and SO about aggregate persistence, and watched a few DDD courses on Pluralsight, but I could find a direct and detailed answer.

Thank you

In the context of a web application where we handle only one command per request in a stateless fashion, do we always have to load/save aggregates as one atomic unit? Why is it recommended not to partially load/save aggregates? What are the fundamental reasons behind this rule of thumb?

Some references where I found this recommendation (but no real explanation why):

DDD: do I really need to load all objects in an aggregate?

How to work with large aggregate roots?

I could only think of caching but I think there is more. Maybe inconsistency by concurrent writers?

Notes: I have read Eric's blue book up to the end of Aggregates chapter, iterated over most of the questions in SE and SO about aggregate persistence, and watched a few DDD courses on Pluralsight, but I could not find a direct and detailed answer.

Source Link
geeko
geeko
  • 256
  • 2
  • 12

Importance of loading/saving complete aggregates at once in DDD

In the context of a web application where we handle only one command per request in a stateless fashion, could somebody point me to concrete examples of things that could go wrong if we do not load/save aggregates as one atomic unit? Why do we insist on not to partially load/save aggregates? What are the fundamental reasons behind this rule of thumb?

I could only think of caching but I think there is more. Maybe inconsistency by concurrent writers?

Notes: I have read Eric's blue book up to the end of Aggregates chapter, iterated over most of the questions in SE and SO about aggregate persistence, and watched a few DDD courses on Pluralsight, but I could find a direct and detailed answer.

Thank you