Domain modeling as abstraction
The origins of bookkeeping
Check out the line-up at Clojure/conj. Tickets are still available.
Please take the State of Clojure Survey! This annual survey is how the Clojure community understands itself. We want to hear from you!
Sometimes you find a rich vein of an idea and follow it wherever it leads. I was lucky enough to find such a vein when preparing what became my first book. And I think I’ve found another rich vein when researching abstraction. These ideas were the center of my recent Heart of Clojure talk (video in production and coming soon). And they’re also the bedrock on which I am writing my new book. I want to give you a peak under the outer layers.
To explain, let’s use the example of a bank. Way before the idea of bookkeeping, when wealth was measured in gold, a bank was a secure place to keep your gold. Each account was a vault.
When one person wanted to transfer money to another person, the gold was literally moved from one vault to another.
But gold is heavy (and tempting to steal). Someone had the bright idea that we don’t need to move the gold. Instead, we can write down how much we would have moved in books. That is, instead of money being gold and each account being a vault, what if we made money a number we wrote down and each account a book?
If that’s the case, then we can make a “transfer” a debit to one account and a credit to another. That is, we write how much we take out in one book and write the same amount as how much we put in the other book.
If we do it right, we should come out to the same answers in the end, without having to move that heavy gold. As a side benefit, we’ll be able to answer our angry clients who wonder where all of their gold went. We’ll be able to show all of the transfers in their account book.
But what’s more important is to know that the two bank systems, keeping gold and keeping books, will give us the same answer in the end. In other words, we want this to be true:
Let’s say we run both systems in parallel as an experiment. We first inventory the gold in the accounts into accounting books (red arrow on the left). When we make a transfer of gold from one account to another (blue arrow at bottom), we also record a debit and credit (red arrow at the top). Then we inventory the amount of gold in our accounts. We should have the same amount as indicated in our books. If we can do that, then we don’t have to lug around our heavy gold—or even open up the vaults until we need to give gold back to the client.
This type of diagram is called a commutative diagram. We can take the red path or the blue path and arrive at the same answer. This idea is key to why we can bank either way, with vaults or with books. They are equivalent systems for a lot of purposes.
In fact, mathematicians have a term. They would say that keeping books is a homomorphism of keeping vaults. That is, there’s a mapping from vaults to books that ensures you get the same answer with either system. And you’re not just mapping the gold to numbers (the data, let’s call it). You’re also mapping the gold transfer to a debit+credit transfer (the operations).
In fact, because they are equivalent (and gold is fungible—one ounce of gold is replaceable with another ounce of gold), we say that the homomorphism goes the other way, too. That is, we can map from books back to vaults of gold. When the homomorphism goes both ways, mathematicians call that an isomorphism.
Anyway, enough with the mathematical terms. The cool thing is that because these systems are equivalent, we can start to say they’re both implementations of something more abstract, namely accounting.
Accounting is an abstract domain about accounts and transfers, and both the concrete domains of vaults and books map to that abstract domain. A mapping from concrete to abstract domains is called an abstraction. Note that the abstraction is not the thing you map to, but the mapping itself. By mapping, we mean a function that can take those concrete things and specify what abstract things they correspond to.
For instance, in the gold bank, an amount of gold maps to an account balance. And moving gold from one vault to another maps to a transfer. You would find similar mappings from book banks to the same concepts in abstract accounting.
And, because we’ve built it correctly, we can also map from abstract accounting back down to either of the accounting systems.
Which is great because when they were converting from a gold bank to a book bank, they needed to follow this path:
In the twentieth century, when banks were digitizing their accounting systems, they had to develop a new concrete form of accounting that of course also mapped to abstract accounting.
And then they had to manually convert the books into database rows:
When someone becomes an accountant, they are trained and certified to perform the operations (like transfer) so that they maintain the isomorphism with abstract accounting. In the computerized accounting, a programmer had to define the steps needed to perform operations so that they maintained the isomorphism. So, in a way, the programmer had to understand abstract accounting enough to code it.
This encoding of the abstract domain in code is one half of domain modeling. You have to understand the abstract data and the operations enough to ensure an isomorphism with the abstract domain. The other half of domain modeling is what accountants did centuries ago, which is to figure out that there was an abstract accounting to begin with. And we’ll talk about that in the next issue.