Your computer systems surely contain several structured and relational databases. You must regularly make copies to avoid losing information. Despite these precautions, you lose all the intermediate states (system states after a past event) of your information systems.
If all you are interested in is the final state, it is not too serious. However, it is a safe bet that one day, you will have to answer questions like:
- How much time elapses between the moment a customer puts an item in their virtual shopping cart and the moment they complete their transaction?
- How many times has this item been removed from a shopping cart?
- What was the order’s status before the crash?
If you have not defined these needs during the initial design of your system, you will not be able to answer such questions. Of course, you will be able to do it, but only when the necessary features are deployed… And again, you will only have data from then on.
So I propose a solution that you can implement first and that will allow you to answer these questions at any time, and even those that you have not yet thought of: CQRS and Event Sourcing.
The strength of this duo comes from Event Sourcing (I will talk about CQRS in a future post).
Do you remember everything you’ve heard about side effects? Among other things, that you should do everything to avoid them?! Well, in this case, these effects are the only things that matter.
How does Event Sourcing work?
In this type of system, we do not keep the actual data, but rather its effect, in the form of past events. For example, if I launch the following command:
var command = new AddItemToCart(cartId, itemId);
The system will create the following event:
var @event = new ItemAdded(cartId, itemId);
One of an events system’s strengths is that it is now possible to follow the withdrawals made to the system, since instead of deleting the information, we add some:
var command = new RemoveItemFromCart(cartId, cartItemIndex);
Which will create the following event:
var @event = new ItemRemoved(cartId, cartItemIndex);
In this system, all the events will derive from basic classes:
public class EventBase { public Guid Id { get; set; } public int Sequence { get; set; } public DateTime TimeStamp { get; set; } }
An infrastructure class will also be necessary in order to make sure that all the events are assigned a date and a sequence.
Basic principle
In such a system, only the events have value. They reflect what actually happened. These events will serve to build reading patterns specific to each interested system. They will each have their small database to answer their immediate needs, and changes will only affect one system.
And then?
In my next post, I will go into more details and give some examples of the value brought by the events preserved in this way.
