Obviously there are novel parts, because the transactions that alter balances are different in every application, and each has its complex "business" logic: undoing a reversed sale is completely different from undoing a mass of accumulated incorrect VAT amounts.
My idea is that a reusable ledger, as a service or library, would be too distant from actual needs to provide much value.
Consider the example database state in the article:
Transfer ID Description ┃ user receivables available
1 order created ┃ -$10 $10
2 payment received ┃ -$10 $10
3 partial refund ┃ $5 -$5
A real application cannot go very far with this kind of "description": every type of transaction needs specific data, whose complexity dwarfs the double-entry ledger mechanism.
For example "order created" transactions need a reference to an order with details of what has been ordered, "payments" need a reference to a collections of debts that they are meant to pay and details of how they have been paid, "refunds" are actually many types and need a reference to what they are refunding.
Real accounts are also much more complex than a history of changes and a computed balance: for example, some of them need to be included in accounting calculations and reports in various roles, with largely arbitrary relationships and accounting criteria, while some are linked to real-world persons.
Comparing the two ledger implementations that the article references is instructive: Pgledger has simple ID columns for accounts and transfers, and it is up to the application to use them as foreign keys from the interesting tables, while TigerBeetle also offers some generic "user data" and "code" columns with arbitrary data and suggests having a separate "control plane" database.
My idea for for this to add metadata to the transfers, likely with a jsonb column. But I agree that the ledger won't encompass everything. You would still have other database tables and then you'd store domain identifiers in the ledger and/or ledger identifiers in your other tables.
