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.
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.