Ilja Tollu (10) [Avatar] Offline
#1
Good morning, Chris!

Thank you for the book!

After reading the latest chapter I have been thinking of one case.

Consider a banking transaction. Two-legged one, to simplify a little bit. There are two accounts and one transaction. What are aggregates (DDD) here? Obviously, we can't manipulate accounts separately, because the state can become inconsistent. So, an accounting transaction itself could be an aggregate, am I right? There are not so many events in the lifecycle of such aggregate.

But if we take an accounting transaction as the aggregate, there is another issue: how do we shard all the data? Ideally, all accounting transactions for a given account should occure in a single shard. This way we could extract all the account's transactions with one select for sure. But we can't partition transactions this way because of their sharing nature. If transactions are spread among several shards, we must query each and every shard to make sure that there are no missing transactions left when calculating an account's current state.

I feel, that here we should implement a multi-step workflow, where first accounting transactions are stored, and then from the flow of these transactions, the accounts' state is changed. Maybe, not a saga. Because after an accounting transaction is saved, there is no need to compensate. At least, within the borders of that transactions. But I'm afraid I'm missing something.

What would be a suitable approach in such situations?

Thank you!
148991 (1) [Avatar] Offline
#2
The common pattern here would be to create secondary indexes to avoid having to scan many shards.
Ilja Tollu (10) [Avatar] Offline
#3
Thanks for reply!

Do you know any sources (books, blogs, youtube), where some information is provided about this technique? A use case example would help, too.

What I'm trying to understand, is how to warrant that all transactions are processed up to some point in time, while being able to query a single shard to get all operations on a given account.

Happy New Year!
ceracm (102) [Avatar] Offline
#4
Ilja Tollu wrote:

Consider a banking transaction. Two-legged one, to simplify a little bit. There are two accounts and one transaction. What are aggregates (DDD) here? Obviously, we can't manipulate accounts separately, because the state can become inconsistent. So, an accounting transaction itself could be an aggregate, am I right? There are not so many events in the lifecycle of such aggregate.



An Account is an Aggregate. A TransferTransaction could also be an aggregate.
An aggregate is "internally" consistent in the ACID sense.
A saga would be used to maintain (Eventual) consistency across aggregates.
Bobby R (3) [Avatar] Offline
#5
In the "Exploring CQRS and Event Sourcing" ebook, they talk about a process manager, which can be used to coordinate actions between aggregates. They distinguished it from a saga, it seems to have to do with the definition of "saga" from the paper it was originally introduced in. I think a process manager deals with things that are presented to the user as a single action, whereas a saga deals with things that are more likely to take a long time. So for example, completing the payment + creating the order could be handled by a process manager, but the whole order flow might be completed by a saga, because of things being picked from inventory as part of a later action.