Image for post
Image for post

CQRS & Events Sourcing avec GCP (1/3) : Introduction

Renaud Chardin
Jun 25 · 4 min read

Cette série d’article à pour but de vous introduire deux design pattern d’architecture logiciel que sont le CQRS et l’ Event Sourcing. Ils sont souvent liés, par nature, mais peuvent être utilisés l’un séparément de l’autre. On les mettra ensuite en action dans les produits de la GCP


Command Query Responsibility Segregation (CQRS)

Comme se magnifique nom barbare le décris, le CQRS est un design pattern qui propose de faire une séparation entre les lecture et les écritures dans votre application. Cette séparation se fait au niveau du model de donnée, mais peut également se faire au niveau projet et des services qui le compose.
En effet il est possible, en plus de bien séparer le model de donnée, de réaliser un (micro) service qui s’occupe de toute la partie écriture et un autre qui s’occupe de la partie lecture.

CQRS Pattern Schema
CQRS Pattern Schema

On voit sur schéma la séparation au niveau de nos services et de nos modèle, mais si on suit notre logique, on peut également séparer les langages de programmation ainsi que le choix de base donnée.

Image for post
Image for post

On peut remarquer ici qu’il y a deux bases de donnée, ce qui implique que, comme on l’a vu précédemment, on peut avoir des technologies différentes pour nos micro services, on peut également avoir plusieurs types de base de données (SQL/NoSQL) et il n’y a aucune contrainte technique à le faire.

Avantages :

  • Scalabilité et performance
  • Gestion d’accès concurrent
  • Définition des modèles simplifiés

Inconvénients :

  • Synchronisation des modèles
  • Maintenance et administration plus complexe
  • Consistance des données de lecture pas garanti à 100%

Event Sourcing

L’event sourcing est également un design pattern qui a lui pour but de ne plus baser ça source donnée sur un état complet d’un objet, mais sur les événements arrivés sur cette objet. Cela veut dire que notre source de vérité n’est plus l’objet en lui même, mais chacun des événements de son cycle de vie, stocké dans un “Event Store”. En partant de ce principe, il y a deux règles d’or : l’event store est “append only” et il est interdit d’altérer un event. Concernant la seconde règle, cela implique que si il y a une erreur il faudra un event de correction pour rectifier l’erreur.

Image for post
Image for post

Avantage:

  • Performance, no dead lock et scalable (append only)
  • Audit trail par design
  • Simple à comprendre pour le business
  • Flexible, pas de dépendance vers le model de lecture
  • Consultation de l’état d’un objet dans le passé

Inconvénients:

  • Peut être difficile à appréhender côté développement
  • L’agrégation de plusieurs store peut être complexe
  • Les modifications de modèle sont plus complexe
  • Il faut commencer le projet avec ce pattern

CQRS et Event Sourcing

Pourquoi ces deux patterns sont si souvent présentés conjointement ? On remarque après leurs descriptions qu’ils se complètent quasi parfaitement, en effet la partie écriture (command) va résulter d’un event et on va stocker cet event dans un event store. Pour la partie lecture, nous avons deux choix : soit lire l’event store, reconstituer un état à partir de tout les events précédent et le présenter, soit créer un système de dénormalisation. Cette couche de dénormalisation va intercepter un event, appliquer cette event sur l’état de d’objet concerner et le stocker dans une base de donner de lecture. ce principe permet de d’adapter ou créer plusieurs modèle de lecture, adapter et performant pour la lecture. La dénormalisation permet de restructurer notre objet et de le préparer à l’exposition extérieur : plus les données sont adaptées à la lecture, moins la donnée doit être traitée et plus la lecture est performant. Prenons l’exemple d’une api REST qui expose les données au format json, si la donnée de lecture est stocké dans une base de donnée NoSql type MongoDb, au format json, il n’y aura pas ou peu de transformation entre la DB et l’exposition REST, et on sera par conséquent très performant. Un bon schéma est toujours interessant pour illustrer un long discours.

Image for post
Image for post

On introduit ici la notion de bus. Dans le cas du “command bus”, il est présent pour des raisons de scalabilité, mais “l’event bus” est très important, c’est lui qui permet cette dénormalisation en écoutant le bus des événements afin de répercuter chaque command à notre base de lecture. Passer par un bus permet également de créer plusieurs domaines de lecture sans avoir un impact sur l’existant. Il n’est donc pas interdit de créer plusieurs base de lecture pour different besoin, afin d’éviter du code compliqué et d’améliorer la performance et la sécurité sur les données exposées.

Avantages:

  • Scalabité
  • Performance
  • Flexibilité

Inconvénient:

  • Complexité de mise en place
  • Changement de paradigme pour le stockage de donnée

Dans l’étape 2, nous allons voir comment mettre en place notre Command Handler dans la GCP.

CodeShake

Learnings and insights from SFEIR community.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch

Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore

Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store