Téléchargé parEric De Carufel
CQRS + Event Sourcing
Le document présente les concepts de CQRS (Command Query Responsibility Segregation) et de l'Event Sourcing comme solutions pour une architecture logicielle robuste en séparant les commandes des requêtes. Il souligne l'importance de modéliser le comportement et non la structure, ainsi que la capacité à rejouer les événements pour assurer la flexibilité. L'accent est mis sur la performance, l'évolutivité et la gestion d'événements dans le cadre d'un système décentralisé.
Contenu connexe
CQRS + Event Sourcing
- 1. CQRS + EVENT SOURCING Desconcepts de design pour une architecture à toute épreuve
- 2. SÉPARATION DES COMMANDESET REQUÊTES © Pyxis Technologies inc. 2
- 3. SYSTÈME TRADITIONNEL Données relationnelles Mise àjour BD Logique d’affaire CRUD Interface usager © Pyxis Technologies inc. 3
- 4.
- 5. POURQUOI CONTINUE-T-ON? © PyxisTechnologies inc. 6
- 6. POURQUOI CONTINUE-T-ON? © PyxisTechnologies inc. 7
- 7.
- 8. SYSTÈME TRADITIONNEL Données relationnelles Mise àjour BD Logique d’affaire CRUD Interface usager © Pyxis Technologies inc. 9
- 9. SÉPAR AT ION 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. CQRS - C OM 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. 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. CQRS Commandes Changel’é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. EST-CE QU’ON ATERMINÉ? © Pyxis Technologies inc. 14
- 14. CQRS - C OM 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. CQRS + EVENTSOURCING É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. EVENT SOURCING Modélise lecomportement 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. LES ÉVÉNEMENTS RollingSnapshot 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. CQRS PIPELINE Event store Userinterface Commands © Pyxis Technologies inc. Domain changes Events Denormalizer Read models
- 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
Notes de l'éditeur
- #4 ** 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
- #5 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
- #7 Est-ce qu’on ne fait que suivre les autres?
- #8 - 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
- #9 Faite-moi confiance mais la marche est haute!
- #10 ** 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
- #11 ** 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
- #12 ** 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
- #13 ** 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.
- #14 ** L’asynchronicité fait partie du système au lieu d’être gérée comme une exception
- #15 **On a les command et les requêtes** Il nous manque les événements
- #16 ** 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
- #17 ** 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.