Historic Modeling

There is one pattern for using definitive behavior that I failed to mention in the previous post. This is perhaps the most important of them all, so it deserves special treatment.

Historic modeling is quite simply storing a history of actions, not the current state of a system. The current state is mutable, whereas history is fixed. Once something has been done, it cannot be undone, and it cannot be changed. A history is an ever growing log of permanent records.

One example of historic modeling from the real world is a chess game. The position of the board changes regularly during the course of a game. The position is dynamic. Yet the record of moves does not change. Once a move is made, it cannot be taken back or changed.

Another example is a checkbook register. The current balance can change over time, but the history of checks, once written, never changes.

Advantages of historic modeling
History is sufficient. Given a history of a system, it is trivial to go back to any point in time to construct it's state. If you have a record of chess moves, you just make each move in turn to produce the board position at every point in the game. If you have a ledger of checks, you can just add up the amounts including the opening balance up to a certain point in time. The current state doesn't contain enough information to reconstruct the history, but the history is sufficient to reconstruct the current state.

History is atomic. Each action in the history has happened. Actions not yet in the history have not. There is no middle ground. This is why banks keep ledgers of account transfers, rather than trying to decrement one account balance and increment another. Balance, being state, is not atomic.

History is consistent. Two people comparing notes can easily disagree on the current state of a system. To come to an agreement, they must compare histories. That's why the bank sends you a list of transactions at the end of each month, rather than just your account balance. That's the only way to reconcile your version of the truth with your bank's. Eventually, all parties will come to agree on the same version of history.

History is transparent. Logging and auditing systems exist to help us trace anomalies to their source. Without them, all we could do is look at the current state and wonder if it is correct. It is relatively easy to hide money in a series of accounts; but if you must produce an accurate history of transactions, each one can be called into question.

History as definitive behavior
So what does historic modeling have to do with definitive behavior? After all, history is always growing, while definitive behavior is something that doesn't change during the life of an object.

While the history of a given system changes, each event in history is constant. Once it is added to history, it cannot be changed. The behavior of the event is definitive, even if the history of events is dynamic.

The effect of an event might change over time. For example, you might think you have enough in your account to write that check, only to learn later that your spouse made a withdrawal beforehand. In your original history, that check left a positive balance in the account. But after learning about other events, you discover that the check left you overdrawn. Still, that doesn't change the fact that the check was written for a certain amount.

History in practice
By the above discussion, a historic model is a database that allows inserts, but no updates or deletes. Every time you need to make a change, you insert the appropriate type of record. To determine the current state of the system, you need to query the aggregate of history.

This is obviously impractical. Such a database would grow without bounds. The aggregate queries would get slower over time and eventually make the system unusable. We need one more observation to make it all work.

A system is historic if it appears to be so, whether it actually works as advertised. This observation allows for optimizations like caching, archiving, and pruning. As long as there is some level of abstraction at which you cannot see that the optimization is taking place (without using a stopwatch), then you can still claim to have a historic model. Future posts will discuss these optimizations in detail.

One Response to “Historic Modeling”

  1. Adventures in Software » Blog Archive » Entity Fact Diagrams Says:

    [...] Historic modeling is the technique of representing a solution as a history of discrete events. This differs from static modeling, which represents the solution as a snapshot. The static model is concerned with the state of the system, whereas the historic model is more concerned with how it got there. [...]

Leave a Reply

You must be logged in to post a comment.