Event Sourcing PoC
You can find the repositories on GitLab.
Introduction
The objective of this PoC is to showcase the feasibility of using an event sourcing pattern, for the purpose of how governmental institutes deal with datasets.
Motivation
Currently most governmental institutes maintain their own datasets. These datasets usually contain recent states only. This approach introduces challenges if these institutes need to cooperate with one another, as it is quite common that the datasets involved contain conflicting data. Additionally, it is (near to) impossible to determine what the state was at a certain point in time, since generally speaking, only recent states are saved.
Event sourcing
The current approach of dealing with data, has proven to be severly limiting. A
more flexible & efficient approach, would be to utilise an event sourcing
pattern. In a nutshell, it boils down to the recording (into so called
event-stores) of each state change, in the form of an event. In turn,
applications (read models) can playback these events, to generate customised
views of applicable states. As a bonus, events can be replayed to a certain
point in time, providing the ability to retrieve historical states.
Backend
This component acts as an append-only event-store. Events are submitted by the
client, which in turn are consumed by the read-model.
Read model
The read model consumes events that are stored in the event store, to build
views, based on a customisable model, which reflect a particular state. These
views are used by the client, to represent a state to the end-user.
Client
The client gives the end-user the possibility to store events and to retrieve
particular states that have been generated by the read-model.
Diagram
