The title of this article is assumed to not be IT related, but it speaks about java. I just wanted it to be of common sense.
Most people writing software today only speak about what we have (the objects), and not about what we know (the events). And sometimes they refuse to understand the meaning of the knowledge (with its history) in favor of its only content.
But sometimes it can be useful.
“History is not important” means “Giving the money to the wrong person is not important”. Why do I say that ?
If we address a bank check of $100 to a Mr John and then a malicious person adds an ‘s’ to the recipient, it will become Mr Johns. We give the money anyway, and we don’t know that we gave it to the wrong person… In fact, our bank account does not notice the problem, we are debited of $100. We are attacked and we just lost data about the attack.
What is the problem behind ? We lose track of known data just because the state has changed.
How to deal with ? Well it is quite simple : past history won’t change.
Therefore, storing the past data can ensure everything gets tracked. The bank check will be photocopied before and after each event (like someone appending a ‘s’ char to a family name). Therefore we can validate that nothing wrong has happened during the process by scanning the bank check history.
Howto ? You can implement it on your own, but that is really a boilerplate to code.
I have tried the JaVers library and wrote a very small webapp to maintain an in-memory user api (https://github.com/libetl/test-with-javers)
Things stay simple : just keep on persisting your data as you would in a non-event-sourced program, but at the last moment, let JaVers work directly with the repository as following :
interface PersonRepository extends MongoRepository
You are now able to query data as usual, but also examine the changes in data and read some old snapshots : (https://github.com/libetl/test-with-javers/blob/master/src/main/java/org/toilelibre/libe/person/PersonResource.java).
Then, reading the current state of the bank check would need to get
Reading the old values of the bank check is as easy as reading
…And you can figure out that someone replaced “Mr John” by “Mr Johns” by reading
The response will look like this :
property:'to', oldVal:'Mr John', newVal:'Mr Johns'}
Then, you will go beyond things, you will be less materialist and care only about the facts… what matters really to your users.