Fil rouge

Compte en banque

Objectifs

• Transferts d'argent
• Historique

Contraintes

• Pas de débit autorisé
• Opérations asynchrones sur mobile
• Opérations asynchrones avec une autre banque

Scénario 1

• En tant qu'utilisateur
• Sur mon mobile
• Je souhaite effectuer un achat sur un site
• Je n'ai pas de réseau au moment de la transaction
• Je suis impatient (je ne veux pas attendre)

Scénario 2

• En tant que banque externe
• Je souhaite synchroniser mes opérations avec celle de la banque courante
• Remarque : Nous supposons que toutes les opérations sont validées pour les deux banques

CQRS

Mais qu'est-ce donc ?

Ce n'est pas

Qu'une

Représentation par un

Sigle

Ca améliore la

Qualité, la

Rédaction et le

Sens du code

C'est

Quoi ?

Réponds,

Steuplé !

Command

Query

Responsability

Segregation

Command

Responsability:

-

-

-

-

Query

Responsability:

-

-

-

-

S
e
g
r
e
g
a
t
i
o
n

Command

Responsability:

- addAmount

- removeAmount

- clearAccount

- buyBeer

Query

Responsability:

- getInfo

- getHistory

- getDetail

- getBeer

S
e
g
r
e
g
a
t
i
o
n

Avantages

• Séparer lecture et modification
• Réduire la taille des classes
• Organisation code
• Modèle de données différent (projections)

Inconvénients

• Multiplication des classes
• Refactoring
• Modèle de données différent (projections)

Mise en place ?

• Deux classes d'un service
• Création de vues (SQL)
• Event-Sourcing

Event-Sourcing

Mais qu'est-ce donc ?

Event

• Traduction : Événement
• Wikipédia :
  • Événement historique, un fait aux conséquences importantes
  • Événement (probabilités), un résultat d’une expérience aléatoire
  • Communication événementielle, un moyen de communication pour les entreprises et les institutions
  • Programmation événementielle, en informatique, une occurrence d'information sur laquelle un logiciel peut déclencher un traitement (par exemple, une action de l'utilisateur ou une information émise par un autre élément logiciel)
  • — https://fr.wikipedia.org/wiki/%C3%89v%C3%A9nement

Event

• Traduction : Événement
• Une reformulation
  • Fait historique : Le fait est arrivé et les faits s'enchaînent chronologiquement
  • Il existe à l'issue d'une action ou lorsqu'une information est émise
  • Il en résulte un résultat ou une occurrence d'information
  • Ce fait a des conséquences sur le système
  • Ce fait est un moyen de communication dans le système
  • Lorsqu'un fait est connu, nous pouvons alors déclencher un traitement

Sourcing

• Traduction : Approvisionnement
• Wikipédia :
  • L'approvisionnement est une technique ou méthode permettant de livrer un bien, ou un service, à un tiers.
    — https://fr.wikipedia.org/wiki/Approvisionnement
• Reformulation :
  • L'objectif de l'approvisionnement est de pouvoir livrer
    « quelque chose »

Event-Sourcing

• Traduction : Approvisionnement d'événement
• Martin Fowler :
  • Event Sourcing ensures that all changes to application state are stored as a sequence of events. Not just can we query these events, we can also use the event log to reconstruct past states, and as a foundation to automatically adjust the state to cope with retroactive changes.
  • — http://martinfowler.com/eaaDev/EventSourcing.html
• Reformulation :
  • Suite d'événements qui permet de retrouver l'état des données à tout instant du cycle de vie de l'application

Event-Sourcing

Event-Sourcing – Exemple

Combinaison

CQRS + Event-sourcing

Rappels CQRS

• Séparer :
  • Commandes
  • Requêtes
• Le modèle de données peut donc être différent

Rappels Event-Sourcing

• Recevoir des commandes
• Générer des événements
• Les événements sont ordonnés

Combinaison

• C = Command
• Q = Query = Event
• Event-Sourcing pour la responsablité des commandes
• Écoute événements pour générer les vues des requêtes

Exemple

Synchronisation

Comment synchroniser des données sur plusieurs machines ?

Cas 1 : Pas de contrainte

• Caractéristiques :
  • Les différents événements peuvent être joués sans ordre particulier
  • Aucun événement ne peut être refusé
• Exemple :
  • Mise à jour du classement des scores d'un jeu

Cas 2 : Master/slave

• Caractéristiques :
  • Un serveur central (master) est responsable de valider les événements selon leur ordre
  • Son état est prioritaire aux autres machines (slaves)
• Exemple :
  • Synchronisation de documents (≈Google Drive)

Cas 2 : Master/slave

• Problématiques :
  • Si deux esclaves envoient deux commandes conflictuelles, comment gérer le conflit ?
  • Quelle est l'ordre des commandes ?
    • Ordre chronologique d'exécution sur les slaves
    • Ordre de réception par le master
    • Autre

Cas 2 : Master/slave

• Solutions ?
  • Lors d'un conflit sur un slave, supprimer l'état courant et récupérer celui du serveur (=rejouer les événements du serveur)
  • Réaliser un merge
  • Demander une confirmation utilisateur
  • Autres ?

Cas 3 : P2P

• Caractéristiques :
  • Il n'y a pas de serveur de référence
  • Les événements sont ordonnés
  • C'est l'anarchie totale !!!
• Exemple :
  • Synchronisation de documents (≈Bittorent Sync)

Cas 3 : P2P

• Problématiques :
  • Qui a raison ?
  • Quelle est l'ordre des commandes ?
    • Selon une date ? Précision ?
    • Autre

Cas 3 : P2P

• Solutions ?
  • Réaliser un merge
  • Demander une confirmation utilisateur (à quel utilisateur ?)
  • Autres ?

Scénario 1 – Rappel

• En tant qu'utilisateur
• Sur mon mobile
• Je souhaite effectuer un achat sur un site
• Je n'ai pas de réseau au moment de la transaction
• Je suis impatient (je ne veux pas attendre)

Scénario 1 – Une solution

• Conception :
  • Système maître/esclave
  • Avoir un système ES/CQRS sur le serveur
  • Avoir un système ES/CQRS sur le mobile
  • Le serveur est la machine de référence

Scénario 1 – Une solution

• Processus :
  • Lors de l'exécution de la commande, pré-valider sur le mobile selon le dernier état connu
  • Lorsque le réseau revient : resynchroniser (envoyer les commandes)
  • Le serveur valide la commande
  • En cas de conflit : réinitialiser l'état des données sur mobile et informer l'utilisateur

⚠ On accepte l'échec de l'opération ⚠

Scénario 2 – Rappel

• En tant que banque externe
• Je souhaite synchroniser mes opérations avec celle de la banque courante
• Remarque : Nous supposons que toutes les opérations sont validées pour les deux banques

Scénario 2 – Une solution

• Conception : Système p2p
• Avoir un système ES/CQRS dans chaque banque
• Synchroniser les événements dans l'ordre d'exécution

Scénario 2 – Un problème

Scénario 2 – Une solution

• Les opérations « removeAmount » ne seront acceptées que par une seule des banques

• L'ensemble des commandes pouvant résulter en un conflit sont exécutées sur une seule machine
• Les autres commandes peuvent être exécuter sur d'autres machines, avec la garantie de non-conflit ultérieur

Conclusion

Que retenir

CQRS

• Command Query Responsability Segregation
• On sépare les opérations de lecture et d'écriture
• Le modèle de données peut varier pour chacun des besoins

Event-sourcing

• Je reçois des commandes (=opération d'écriture)
• Je valide ou non les commandes (contrôle)
• Je crée des événements (fait validé)
• Les écouteurs mettent à jour leur vues (pour des opérations de lecture)
• Il est possible de récupérer l'état de ma base à tout instant

Synchronisation

• Pas de contrainte : 😂
• Maître/esclave
  • Serveur de référence
  • Conflit ?
    • Réinitialiser l'état du slave
    • Confirmation utilisateur
• P2P
  • Pas de référence
  • Conflit ?
    • Confirmation utilisateur
    • Limite d'action des commandes

Questions ? Remarque ?

Une question nous avance
Une remarque nous corrige