Paradigm Shift from Single Model to Commands, Events, and Queries
In an era of software eating the world and where storage and compute power is not expensive anymore it is time to change our paradigm of only using a single model for our data. As our society grew into larger numbers we were in need of systems to keep our records. For years we developed these systems in different ways with a common pattern: a table in a book. During the first digitization of these books we moved to a table in a database. Now it is time to move the flow in our heads into data as well!
In this article I’ll use an example from the Land Administration Office in The Netherlands (’cause I work there ;-) It is easy to connect to or to understand. Land Administration is about who owns a piece of land. Who owns pays taxes and can sell it. Let’s imagine a Person A that owns a piece of land and sells it to Person B. In The Netherlands Person A and Person B need to go to the Notary for the legal transfer which will be put in a Deed, signed by both parties. This Deed will be send to the Dutch Land Administration Office to be published in the Public Register. Now the ownership has been transferred from Person A to Person B.
At the Land Administration Office a System of Records is kept for each piece of land. This used to be on paper. At the local office, there would be huge amount of books with two pages for each piece of land. Whenever a Deed was being processed the eligible book was taken out of the archive and the proper page selected to strike through the former owner and write down the new owner of this piece of land. Note that the Deed was the document received and processed and the transformation into strike through and write down the new owner was a human interpretation. Something was happening inside the head of the clerk who processed the Deed.
Then the Computer System were introduced. Yeah, let’s go digital! Well… Digital in the way that we replaced the paper System of Records with a database System of Records. A step forward but still the same processes and execution as ‘the paper way’. In the last few decades the rise of Computer Systems, Technology and Automation has a huge impact on our ways of working but until the last few years the amount of data that could be processed and stored was not that much.
Today storage is (relatively) cheap as is processing power and memory. There’s no limit on these resources anymore. This is the era of Intelligence which can only exist because of data! If we would like to evolve and apply intelligence we need to respect all data involved. This means the data of the deed and the data (and validation rules) in our heads.
Let’s have a look at the Deed first. The Deed is expressing an action, a ‘do something’. It is commanding for something. Let’s call it just that: a Command. We accepted the Deed for a starter of a process (at the Land Administration Office; it is the outcome of another process — as is another general pattern; see conclusions) and we never developed a data model for it. Now we need to explicitly model the Command to formalize the data used as a trigger of the process.
Next steps are disentangling the process which is in our heads. What we actually do as a first step is Validation. We validate that the Deed is ‘sane’ and the Notary did do its job properly. This is part of the law we execute here. Secondly we check if Person A is able to sell it to someone else. If he or she does NOT own the land currently it should not be possible to sell (duh!).
Once the Deed is validated and accepted we could directly move into editing the current state: strike through the current owner and write down the new owner. This is very plausible … but wait, we’re loosing data here as well. The striking through is data! Writing down the new owner is data too! Oh well, the actual acceptance of the Deed, the outcome of the validation, is data as well! We’re missing out here …
Let’s build up a new stack of data where all accepted Commands are archived. Let’s add an ID for each accepted Command and an timestamp of acceptance. These are the Events that happened on the System of Records. Events have happened before so we need to express them in past tense. So the Command is a Deed which expresses the action of ‘transfer ownership!’ while the Event expresses what has been accepted and changed in the System of Records: ‘ownership transferred’.
Now that we have a stack of Events, the accepted Commands, it is time for the second step in our mental process: what is effect of accepting the Command? Actually this is also captured in the Events. In the example the Event is more explicit: ‘ownership transferred from Person A to Person B’.
This is the input for striking through the record for Person A and writing down the new record for Person B. This is the third step in our mental process. We analyse what the consequences are of the Event which just happened and we transform that in editing the System of Records. Now we can update our View on who is the current owner of this piece of land.
Is this the only view that will be queried for? Probably not! We might need insights on how many pieces of land a certain person has. Or maybe we would like to analyse the movement of people in a certain area (group of registered pieces of land). Or … well, maybe we would like to query for something we don’t know yet. Having a stack of Events on how the System of Records did evolve enables us to build a new Query at a later point in time including all historical data! Wow! Data is power! Let the intelligence come :-D
Concluding: For many decades we developed Systems of Records to keep our administration neat and useful. In the digital space there where reasons to just move from paper to ‘digital’ without any (real) change. Now we don’t have any excuse for ignoring all data involved and if we would like to move forward and make use of intelligence we need to take all data into account. Therefor we need to shift our paradigm of a Single Model and move to explicit Commands, Events and Queries!
As with all paradigms this shift takes some time to get into our system of thinking. In my experience it takes up to several weeks rethinking this shift before it starts to make sense (so please take your time ;-)
Secondly, Events are very natural to our physical world. Things happen all the time simultaneously, parallel and sequential. Computer Systems of these days need to scale up and by doing so they become quite similar to our physical world in the way that things happen all the time simultaneously, parallel and sequential. Both aspects drive the Event Driven patterns. Within the Domain Driven Design community this is elevated into the business domain with Business Events and the architectural patterns ‘Command Query Responsibility Segregation’ (CQRS) and Event Sourcing.
