Snapshot larger than event stream?

[jarchin]

I've managed to distill the events down to a smaller set which has a reduced the problem I had of same data represented in many events. (The issue was the context boundaries not being right).

Now in one of the aggregates, there is an event which holds the data of a bank transfer to a physical account, the partition of the transfer into constituents, the addresses of these constituents (virtual and physical accounts).

This is quite neatly wrapped up in one event.
Additional events come later to actually set the date of the consequent transfers, as they might happen on a later date than the very first, initial transaction.

Now, in the aggregate, there is a ledger modeled, which stores all the transactions in their finest possible granulation. I.e. that is an inmemory representation that is built from that one event. It can be hundreds of transactions from one event.
The physical transactions are fewer (3-4 real bank accounts). But the virtual accounts need of course be represented.

To the question:

I hesitate as to wether this is appropriate for the write model.
The actual book keeping is not this finely granulated, it is not required by the accountant, so that's not why the AR ledger is.
The main reason I see, to have this complete break down into individual transactions, is to be able to address them by their id and revert them (enter a mirrored transaction, referencing this one). That is a write model concern.

But let's say I want to roll up the year, do a snapshot or similar. When serializing that AR's state, I would get a ledger with hundreds of thousands of entries. I wonder if that list would be bigger than the original event list.

And exactly that is what makes me hesitate, a snapshot that is bigger than the list of events it's based off?
That can't be right?

[Ben Kloosterman]

On Sun, Aug 7, 2016 at 7:18 PM, jarchin <jarch...@gmail.com> wrote:

To the question:

I hesitate as to wether this is appropriate for the write model.
The actual book keeping is not this finely granulated, it is not required by the accountant, so that's not why the AR ledger is.
The main reason I see, to have this complete break down into individual transactions, is to be able to address them by their id and revert them (enter a mirrored transaction, referencing this one). That is a write model concern.

I dont like 1 transaction is one aggregate thats too fine grained - maybe in a transaction system /BC  but not the accounting system . I would start with an account ( or cost centre) which would represent a collection of transactions. This collection could have an ID for the transaction eg a addressable  Entity under the account AR. .   

But let's say I want to roll up the year, do a snapshot or similar. When serializing that AR's state, I would get a ledger with hundreds of thousands of entries. I wonder if that list would be bigger than the original event list.

If i understood.  It could  - end of year roll overs in large accounting systems are not trivial and that is not an issue  . It is unusual in the write domain to have a global ledger  , the global ledger is normally aggregated from all the transactions in the accounts, So i would say the aggregation of the ledger is in the read model  , it would normally be in the domain as a collection of accounts . 

That is for a large system for a small system you could do it through a ledger but then your not talking hundreds of thousands of entries.

Ben

[jarchin]

Thanks for the input Ben.

The AR is handling more than 1 transaction, in fact around 10 cmds are routed to it, and it's quite big. (Just wrote another post on it).

The "ledger" is not the accounting ledger at the moment (which is another AR), but I would like the ledger and this transactions ARs event stream to be the very same - after all the transaction events are the very source of truth and the accounting is the single most important side of the business..

If the AR reads accounting entries - i.e. its events are designed exactly like the accounting entries - then the domain logic's db and the accounting is one (which is the actually the very case).