Ilja Tollu (9) [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!