Upon reading the article, my initial thought was that it resonates with the concepts of Event Sourcing. However, as I think deeper, it dawned on me that while there are similarities, they serve different primary objectives. I realized that if the sole purpose is to implement bi-temporality, leveraging Event Sourcing could be somewhat convoluted and indirect.
In contrast, a focused bi-temporality solution could be more streamlined and efficient for cases where the primary need is to maintain historical accuracy with regard to effective and record times. It might entail less complexity in terms of data retrieval and management.
I haven’t gotten far enough into event sourcing to give you a confident answer. Seems like events are the deltas and states are the, well, states, and one could be derived from the other. I’m not sure how event sourcing handles retrospective/prospective changes (to say nothing of range queries in the face of crossing—topic for a future post).
Accounts are typically event sourced. Each posting being an event. In the case of error, the fix is a new event cancelling out the one that is wrong and adding new one that is correct. This way the story of what has happened is logged.
Aside from the data and the real world, it seems like there's a third thing that's likely to be changing: the code. How do you answer the question "what version of the software did we use to process the customer's contract on Tuesday?" And then the follow-up: "how can we check if that version of the software processed the contract correctly?" In many systems that I've worked on, it's not straightforward to run an earlier version of the code, because that code might depend on services that no longer exist.
Great question! We considered the topic of versioning code the same way and quickly concluded that the time it would have mattered are infrequent enough and easily enough fixed manually that we can just ignore them.
This is not to say that someone could build a programming environment that had bi-temporally stamped code. But I think it would have to be baked in. Would make a great PhD thesis.
Hi Kent! Actually, 'a programming environment that had bi-temporally stamped code' is precisely what I've been working on for the last 3 years. If any of your readers are interested, I did a talk recently describing it in more detail: https://www.youtube.com/watch?v=Cq4S7nO1KOo
Hi Kent, I found this article of yours with Massimo Arnoldi that seems to describe the same patterns in depth: "Time Travel: A Pattern Language for Values That Change". It's very nice, I'm rebuilding the examples in Java as I don't grok SmallTalk
Upon reading the article, my initial thought was that it resonates with the concepts of Event Sourcing. However, as I think deeper, it dawned on me that while there are similarities, they serve different primary objectives. I realized that if the sole purpose is to implement bi-temporality, leveraging Event Sourcing could be somewhat convoluted and indirect.
In contrast, a focused bi-temporality solution could be more streamlined and efficient for cases where the primary need is to maintain historical accuracy with regard to effective and record times. It might entail less complexity in terms of data retrieval and management.
I would be intrigued to know your thoughts.
I haven’t gotten far enough into event sourcing to give you a confident answer. Seems like events are the deltas and states are the, well, states, and one could be derived from the other. I’m not sure how event sourcing handles retrospective/prospective changes (to say nothing of range queries in the face of crossing—topic for a future post).
Accounts are typically event sourced. Each posting being an event. In the case of error, the fix is a new event cancelling out the one that is wrong and adding new one that is correct. This way the story of what has happened is logged.
It's fairly modern; just in the last few years. But I'm a fan (did a presentation on it at Pycon a year ago).
Python also has pattern matching and type unions, which I love.
Just an observation: Python dataclasses can make your code simpler/easier to read.
Thank you. I’m not a Pyothonista & I appreciate the teaching.
Aside from the data and the real world, it seems like there's a third thing that's likely to be changing: the code. How do you answer the question "what version of the software did we use to process the customer's contract on Tuesday?" And then the follow-up: "how can we check if that version of the software processed the contract correctly?" In many systems that I've worked on, it's not straightforward to run an earlier version of the code, because that code might depend on services that no longer exist.
Great question! We considered the topic of versioning code the same way and quickly concluded that the time it would have mattered are infrequent enough and easily enough fixed manually that we can just ignore them.
This is not to say that someone could build a programming environment that had bi-temporally stamped code. But I think it would have to be baked in. Would make a great PhD thesis.
Hi Kent! Actually, 'a programming environment that had bi-temporally stamped code' is precisely what I've been working on for the last 3 years. If any of your readers are interested, I did a talk recently describing it in more detail: https://www.youtube.com/watch?v=Cq4S7nO1KOo
Actually Martin Fowler in his https://martinfowler.com/eaaDev/EventSourcing.html discuss about `Code Changes` and made references to https://martinfowler.com/eaaDev/TemporalProperty.html BTW very likely to the Kent example, and also https://martinfowler.com/eaaDev/AgreementDispatcher.html but as Martin closed that section: " I would be inclined to do it by ensuring any change to the processing scripts was handled in the same way as any other update - through an event. (Although by now I'm certainly drifting away from observation to speculation.)"
Hi Kent, I found this article of yours with Massimo Arnoldi that seems to describe the same patterns in depth: "Time Travel: A Pattern Language for Values That Change". It's very nice, I'm rebuilding the examples in Java as I don't grok SmallTalk
Not easy to read code blocks, no highlights