CQRS + EVENT
SOURCING

Des concepts
de design
pour une
architecture à
toute épreuve
SÉPARATION DES COMMANDES ET REQUÊTES

© Pyxis Technologies inc.

2
SYSTÈME TRADITIONNEL
Données
relationnelles
Mise à jour BD

Logique
d’affaire

CRUD

Interface
usager
© Pyxis Technologies...
PROBLÈMES

© Pyxis Technologies inc.

4
POURQUOI CONTINUE-T-ON?

© Pyxis Technologies inc.

6
POURQUOI CONTINUE-T-ON?

© Pyxis Technologies inc.

7
CONFIANCE…

© Pyxis Technologies inc.

8
SYSTÈME TRADITIONNEL
Données
relationnelles
Mise à jour BD

Logique
d’affaire

CRUD

Interface
usager
© Pyxis Technologies...
SÉPAR AT IO N D ES C OMMAN D ES ET D ES R EQU ÊTES
Données
relationnelles
Mise à jour BD
Logique
d’affaire

Requêtes

Comm...
CQRS -

C O M M A N D A N D Q U E R Y R E S P O N S A B I L I T Y S E G R E G AT I O N

Données
relationnelles
Mise à jour...
PASSONS À L’ACTION
 Utiliser des verbes pas des noms
 Il faut analyser comment l’usager utilisera le système

 Pas d’éd...
CQRS
 Commandes
 Change l’état du système
 Asynchrone (pour le meilleur et pour le pire)

 Requêtes







Ne ch...
EST-CE QU’ON A TERMINÉ?

© Pyxis Technologies inc.

14
CQRS -

C O M M A N D A N D Q U E R Y R E S P O N S A B I L I T Y S E G R E G AT I O N

Données
relationnelles
Mise à jour...
CQRS + EVENT SOURCING

Événements

Dénormaliseur

Event Store

Gestion
d’événements

Service BUS

XML

SQL
HTML

Modèle de...
EVENT SOURCING







Modélise le comportement non pas la structure
Séquentiel et cumulatif
Peut rejouer les événeme...
LES ÉVÉNEMENTS
 Rolling Snapshot
 Optimisation

 Aggregate root
 Transaction garantie uniquement dans ce cadre
 Const...
CQRS PIPELINE

Event store

User interface

Commands

© Pyxis Technologies inc.

Domain changes

Events

Denormalizer

Rea...
LA FIN
 Questions?
 Rappelez-vous
 Les événements sont la seule vérité
 Le cœur du système est le domaine
 Le modèle ...
Prochain SlideShare
Chargement dans…5
×

CQRS + Event Sourcing

3 771 vues

Publié le

Cette présentation décrit un concept architecture qui n'est pas nouveau, la séparation des commande et des requête et un autre les événements comme source d'information.

Ensemble ils forment un duo imbattable pour développer des application performantes et robustes.

Publié dans : Technologie
0 commentaire
4 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 771
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2 114
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
4
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • ** Les application traditionnelle sont découpées en couches.** Tout passe par la logique d’affaire, les commandes et les requêtes.** Il est facile de faire les deux en même temps** Problèmes de performance (optimisé read ou write)** Ajout de cache pour performance** Concurence en écriture, lock de table** La séparation évite qu’une commande retourne de l’information et qu’une requête modifie le modèle
  • Modèle descriptifCRUD (Create, Read, Update, Delete)Domaine d’affaire définit par des nomsModèle rigide - Base de donnée difficile à modifier sans affecter les systèmesDifficile d’utiliser la modélisation DDDModèle anémiqueLogique d’affaire du côté client ou pire dans la tête des utilisateursScalabilityLa seule option est un BD plus grosse (ou LoadBalancing)Complexité accidentelleModèle de requête de plus en plus complexe et lent
  • Est-ce qu’on ne fait que suivre les autres?
  • - Les outils sont présents et faciles- Supporté par toutes les plateformes- Modèle bien connu- Les concepteur de base de données (SQL, Oracle, …) font la promotion ($) de ce modèle.- Confort / résistance au changement
  • Faite-moi confiance mais la marche est haute!
  • ** Les application traditionnelle sont découpées en couches.** Tout passe par la logique d’affaire, les commandes et les requêtes.** Il est facile de faire les deux en même temps** Problèmes de performance (optimisé read ou write)** Ajout de cache pour performance** Concurence en écriture, lock de table** La séparation évite qu’une commande retourne de l’information et qu’une requête modifie le modèle
  • ** La séparation évite qu’une commande retourne de l’information et qu’une requête modifie le modèle** Mauvaise chose de faire des requête directement à la base de données
  • ** L’ajout de la gestion des commande et du modèle de lecture renforce le principe de séparation** Comment synchroniser 2 BD?** On a besoind’avoirl’information live en tout temps.** Coming out – On n’estjamais live** Capitalisersurce fait plutôtque de s’enplaindre.** Dans ce contexte la base de donnée est complètement cachée elle est même inutile
  • ** Une base de données une représentation passive d’un système** Il faut parler d’action et pas de données** Le concept de command fonctionne partout : Commander une pizza par exemple.** Se poser la question si une commande peut être refusé est sais et démontre qu’on porte attention aux règles d’affaires plutôt qu’aux données.
  • ** L’asynchronicité fait partie du système au lieu d’être gérée comme une exception
  • **On a les command et les requêtes** Il nous manque les événements
  • ** L’ajout de la gestion des commande et du modèle de lecture renforce le principe de séparation** Comment synchroniser 2 BD?** On a besoind’avoirl’information live en tout temps.** Coming out – On n’estjamais live** Capitalisersurce fait plutôtque de s’enplaindre.** Dans ce contexte la base de donnée est complètement cachée elle est même inutile
  • ** Plusieurs façon de voir la vérité dépendamment du point de vue. Ex: Changement d’adresse, Paye (dépense vs gain)** La seule vérité du système réside en ce qui c’est réellement passé, donc dans les événements.** Le modèle de lecture peux être persisté dans la forme la plus proche de sa consultation.** Le processus de mise à jour du modèle passe par la réception et le gestion des événement et par la transformation (dénormalisation) de l’événement en données utiles** Le Service BUS assure le transport des événement entre les différents systèmes.
  • CQRS + Event Sourcing

    1. 1. CQRS + EVENT SOURCING Des concepts de design pour une architecture à toute épreuve
    2. 2. SÉPARATION DES COMMANDES ET REQUÊTES © Pyxis Technologies inc. 2
    3. 3. SYSTÈME TRADITIONNEL Données relationnelles Mise à jour BD Logique d’affaire CRUD Interface usager © Pyxis Technologies inc. 3
    4. 4. PROBLÈMES © Pyxis Technologies inc. 4
    5. 5. POURQUOI CONTINUE-T-ON? © Pyxis Technologies inc. 6
    6. 6. POURQUOI CONTINUE-T-ON? © Pyxis Technologies inc. 7
    7. 7. CONFIANCE… © Pyxis Technologies inc. 8
    8. 8. SYSTÈME TRADITIONNEL Données relationnelles Mise à jour BD Logique d’affaire CRUD Interface usager © Pyxis Technologies inc. 9
    9. 9. SÉPAR AT IO N D ES C OMMAN D ES ET D ES R EQU ÊTES Données relationnelles Mise à jour BD Logique d’affaire Requêtes Commandes Interface usager © Pyxis Technologies inc. 10
    10. 10. CQRS - C O M M A N D A N D Q U E R Y R E S P O N S A B I L I T Y S E G R E G AT I O N Données relationnelles Mise à jour BD Modèle de lecture Domaine Gestion des commandes Requêtes Commandes Interface usager © Pyxis Technologies inc. 11
    11. 11. PASSONS À L’ACTION  Utiliser des verbes pas des noms  Il faut analyser comment l’usager utilisera le système  Pas d’édition de données mais plutôt des actions sur le domaine  Passer des commandes  Message sérialisable  Mode impératif  Langage clairement défini  Est-ce qu’une commande peut être refusée? © Pyxis Technologies inc. 12
    12. 12. CQRS  Commandes  Change l’état du système  Asynchrone (pour le meilleur et pour le pire)  Requêtes       Ne change pas le système Modèle dénormalisé Distribuable (Charding) Scalable Représente au moins 90% des accès au système Performance © Pyxis Technologies inc. 13
    13. 13. EST-CE QU’ON A TERMINÉ? © Pyxis Technologies inc. 14
    14. 14. CQRS - C O M M A N D A N D Q U E R Y R E S P O N S A B I L I T Y S E G R E G AT I O N Données relationnelles Mise à jour BD Modèle de lecture Domaine Gestion des commandes Requêtes Commandes Interface usager © Pyxis Technologies inc. 15
    15. 15. CQRS + EVENT SOURCING Événements Dénormaliseur Event Store Gestion d’événements Service BUS XML SQL HTML Modèle de lecture Domaine Gestion des commandes Requêtes Commandes Interface usager © Pyxis Technologies inc.
    16. 16. EVENT SOURCING       Modélise le comportement non pas la structure Séquentiel et cumulatif Peut rejouer les événements Ajout seulement Possible de construire n’importe quel modèle structuré Audit © Pyxis Technologies inc. 17
    17. 17. LES ÉVÉNEMENTS  Rolling Snapshot  Optimisation  Aggregate root  Transaction garantie uniquement dans ce cadre  Construit à partir des événement  Commandes  ApplyEvent  Events  Ne peux pas échouer  Aucune logique à appliquer © Pyxis Technologies inc. 18
    18. 18. CQRS PIPELINE Event store User interface Commands © Pyxis Technologies inc. Domain changes Events Denormalizer Read models
    19. 19. LA FIN  Questions?  Rappelez-vous  Les événements sont la seule vérité  Le cœur du système est le domaine  Le modèle de lecture est flexible et volatile  Eric De Carufel  eric@decarufel.net  http://blog.decarufel.net  http://pyxis-tech.com © Pyxis Technologies inc. 20

    ×