|
I find it a strange choice to explain double-entry bookkeeping with the example of "one entry for Alice, one entry for Bob". That's really not what it's about. It's obvious that a transaction with two parties could be recorded in two places, but to me the crucial point of double-entry bookkeeping is that it requires two entries for each party of the transaction. So if Alice buys book from Bob, four entries are made. I get that this is supposed to be a simplification for educational purposes, but I find this is simplification is an oversimplification, since it omits the key point. |
If you're building payment rails, that event might itself be one of a pair of events, sourced from a meta-event tracking the transaction intent. (As a meta-point, I find it much more useful to think of the "graph" in accounting as having edges not made of money, but of data in a derived-event hierarchy.)
And a first step towards being able to have that mental model is ensuring that you have a good mental model of multiple physical-human actors accumulating events in a structured and atomic way.
But the OP doesn't actually make it clear that this is what the analogy is in service of! And I fear that the OP article will cause more confusion than it solves.