The value of the Event Store’s events (part 2)

By éric de carufel

In the previous post, we saw how to create events based on commands. Why not update the database directly? Why do we need to go through an Event Store? Let’s talk a bit about the current situation… Currently, the majority of systems keep their data in a relational database common to several information systems. The reason for this centralization is simple: it is very easy to share common tables between the different systems. This convenience meets certain needs:

  • Ease of maintenance of common tables
  • Coherent intersystem information
  • Reuse of information

This centralization also has disadvantages that are not negligible. If one or two systems use these tables, that is not a problem, but as soon as you add dependent systems, problems can begin to appear. Often, a new system has a need for information that is not covered by current data. Adding a column to the table will affect all systems that use it. In addition, this new information will be considered pollution for other systems. The amount of information to be carried over the network will also increase.

How to achieve the benefits of centralization without the disadvantages? This is where Event Sourcing is interesting. Considering the business field as a succession of events greatly simplifies the problem. Even though this list of events is distributed across multiple nodes, this is not a problem. Each event is written once and will not change anymore. If the node that contains the events has no more space, we can easily add storage without risk of losing the events we already have. To avoid the loss of events, we can use distributed storage methods such as MongoDB which makes it easy to add nodes to the cluster. In the next post, I will explain in more detail how to make your events evolve over time.

Autres articles qui pourraient vous intéresser

Your Custom Software Creation Partner | Done Technologies

CQRS—Event Sourcing

CQRS is a system architecture or design pattern that separates the act of reading data (query) from taking action (command) in order to produce a system which easily scales and provides some useful benefits (such as “playable” event logs) that make the maintenance of the system less burdensome. Learn more about these topics Articles Clarified...
Custom Software Development | Done Technologies

Les microservices : une architecture Agile — Deuxième partie

Lisez la première partie de cet article ici : « Les microservices : une architecture Agile — Première partie ». Utiliser le DDD (Domain Driven Design) pour créer des microservices En nous appuyant sur la séparation des modèles qu’offre le DDD, nous pouvons rejoindre facilement le même concept qui est à la base des microservices. Il suffit de décomposer...
Custom Software Development | Done Technologies

Microservices: an Agile architecture

The digital era in which we live nowadays requires us to bring several changes to our way of doing things. Businesses that are still seeing software development as a costly burden and not as a strike force, will soon face many important challenges. To surf on the technological wave, businesses need to be able to...