calculations between aggregates?

Mar 10, 2012 at 8:49 AM

Imagine the following scenario: on Customer aggregate entity, we would like to return a value indicating whether she has a pending payment or not. Pending payments are stored in a different aggregate (say Accounts Receivable or AR for short), which is implemented in a different processing node (let me call processor of customer 'Processor.1' node, processor of AR 'Processor.2' for clarity).

In this case, the construction of Customer response (and probably validation of certain customer events) will be dependent on AR status for this customer, which is not mapped in the Entity Cache of Processor.1 node. How should we handle this situation?

In the LMAX architecture article, Martin Fowler wrote a solution: in this case, Processor.1 should return an event (instead of returning the result), which will be routed to Processor.2 (retrieve pending AR if exists), its result will be routed back to Processor.1, which will continue its working. In this case, we must break up the processing of events, and handle the inconsistent state of entities (first event should not update cached customer, but last one should. But in the meantime, we should remember that we're in a middle of constructing a new state, and should be able to continue even after node restart).

From another perspective, entity caches of processor nodes implement a distributed caching scenario. In this case, it is perfectly acceptable to emit a query to the other processors, requesting the current AR status of the customer. However, in this case, we must implement a delicate locking mechanism to avoid using dirty data, and even to avoid deadlocks.

Any ideas on where to proceed?