Multiple Aggregates / Repositories in one Transaction

Question

I have a payment system as shown below. The payment can be made through multiple gift coupons. The gift coupons are issued along with a purchase. The customer can make use o

Answer 1

The answer I would submit would be 'it depends'(tm) as it comes down to what is 'good enough'

The context of both the problem space and the technical implementation are not well known and will affect any acceptable solution.

If the technologies allow it (say in a ACID data store), then it might make sense from a business perspective to use a transaction.

If the technologies do not provide these capabilities, then it might make sense to 'lock' all the coupons and the payments records in order for the updates to be consistent. How long of a lock and what contention might be occurring would need to be investigated.

Thirdly, it could be implemented as multiple transactions/aggregates with the following rough business process strategy.

Note: I'm not defining how the interaction is happening between the aggregates as the technical requirements are not known

1. 'Create' the first aggregate (let's call it the purchase aggregate), which will record the expected payments which identify the coupon(s) to be used.
2. As late as possible, confirm that the current business policies are valid (each coupon is currently valid). If not, cancel/stop the business transaction.
3. Persist the purchase aggregate in a 'tentative' state.
4. interact with each coupon aggregate to 'adjust limit' for the tentative purchase. Reply back with success/failure.
5. the 'adjust limit' will change the available amount of money that is available for other potential purchase aggregates
6. If any of the coupons fail to 'adjust limit', then the purchase is 'being cancelled' and the coupon limits that were approved are re-adjusted back to the pre-purchase request amounts (and the purchase is now in a 'cancelled' state)
7. If all coupons limit are adjusted, then the purchase is now in an 'finalizing' state
8. in the 'finalizing' state, the system now interacts with each coupon aggregate to 'finalize coupon usage' where, possibly, the coupon usage for the purchase is journaled on the coupon aggregate (depends on business logic and need)
9. once all the coupon usages have been finalized, then the purchase aggregate is set to the state of 'approved' and any additional business processes can commence.

A lot of your choices will depend on what is correct from a business and technical capabilities perspective. The pro's and con's of each choice affect the business's success, either now or in the future. 'It depends'(tm)