[btown]

Out of curiosity, how would a clearinghouse layer plug into this in practice? Thinking aloud, would you have an event stream of, say, EntryCreatedEvent, and the clearinghouse would provide streams of of EntryClearedEvent and EntryRejectedEvent - would you join those streams together to derive EffectiveEntry, EffectiveTransaction, PendingEntry, PendingTransaction based on whether all clearing is done on both sides?

[inopinatus]

I would strongly advise against additional event types because the double-entry model is already an append-only journal. At most, I’d encapsulate the creation of a transaction as a structural formality for whatever event stream/bus is in use. The clearance events produced by the clearinghouse need to be more purposeful and work at a domain level for the logic to have any chance of coherent implementation. So it’s a PaymentsCleared event, note the plural because in many systems this is a batch. This is probably followed by events for the creation of records for the aggregate settlement transfers and their subsequent approvals/lodgement/lifecycle with financial institutions/treasury systems.

The most interesting projections from such an event stream are usually just Balance and PendingBalance. I wouldn’t type entries based on status, it’s just a flag (or more likely a timestamp and reason code), and transaction is not distinguished at all, its status is nominally cleared simply when all the linked entries are cleared.