Sum on collection invariant prevent Aggregate root creation/update

Question

I am aware there is a lot of topics on set validation and i won’t say i have read every single one of them but i’ve read a lot and still don’t feel i’ve seen some definite answer that doesn’t smell hackish.

Consider this:

• we have a concept of Customer
• Customer has some general details data
• Customer can make Transaction (buying things from the store)
• if Customer is in credit mode then he has a limit of how much he can spend in a year
• number of Transactions per Customer per year can be huge (thousands+)
• it is critical that Customer never spents a cent over a limit (there is no human delivering goods that would check limit manually)
• Customer can either create new Transaction or add items to existing ones and for both the limit must be checked
• Customer can actualy be a Company behind which there are many Users making actual transactions meaning Transactions can be created/updated concurrently

Obviously, i want to avoid loading all Transactions for Customer when creating new or editing existing Transaction as it doesn’t scale well for huge number of Transactions.

If i introduce aggregate dedicated to check currentLimitSpent before create/update Transaction then i have non-transactional create/update (one step to check currentLimitSpent and then another for create/update Transaction).

I know how to implement this if i don’t care about all ddd rules (or if its eventual consistency approach) but i am wondering if there is some idiomatic ddd way of solving this kinds of problems with strict consistency that doesnt involve loading all Transactions for every Transaction create/update?

Answer 1

it is critical that Customer never spents a cent over a limit (there is no human delivering goods that would check limit manually)

Please read this couple of posts: RC Dont Exist and Eventual Consistency

If the systems owners still think that the codition must be honored then, to avoid concurrency issues, you could use a precomputed currentLimitSpent stored in persistence (because no Event Sourcing Tag in your question) to check the invariant and use it as optimistic concurrency flag.

• Hidrate your aggregate with currentLimitSpent and any other data you need from persistence.

• Check rules (customerMaxCredit <= currentLimitSpent + newTransactionValue).

• Persist (currentLimitSpent + newTransactionValue) as the new currentLimitSpent.

• If currentLimitSpent has changed in persistence while the aggregate was working (many Users in the same Company making transactions) you should get a optimisticConcurrency error from persistence.

• You could stop on exception or rehidrate the aggregate and try again.

This is a overview. It can not be more detailed without entering into tech stack details and architectural design.