CQRS + Event Sourcing
•
7 j'aime•5,751 vues
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.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
En vedette
En vedette (20)
Similaire à CQRS + Event Sourcing
Similaire à CQRS + Event Sourcing (20)
Plus de Eric De Carufel
Plus de Eric De Carufel (8)
CQRS + Event Sourcing
- 1. CQRS + EVENT SOURCING Des concepts de design pour une architecture à toute épreuve
- 2. SÉPARATION DES COMMANDES ET 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. PROBLÈMES © Pyxis Technologies inc. 4
- 5. POURQUOI CONTINUE-T-ON? © Pyxis Technologies inc. 6
- 6. POURQUOI CONTINUE-T-ON? © Pyxis Technologies inc. 7
- 7. CONFIANCE… © Pyxis Technologies inc. 8
- 8. SYSTÈME TRADITIONNEL Données relationnelles Mise à jour BD Logique d’affaire CRUD Interface usager © Pyxis Technologies inc. 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. 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. 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 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. EST-CE QU’ON A TERMINÉ? © Pyxis Technologies inc. 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. 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. 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. 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. CQRS PIPELINE Event store User interface 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
- ** 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.