This document discusses CQRS (Command and Query Responsibility Segregation) and event sourcing architectures. It describes splitting commands and queries into separate pathways to improve scalability and performance. The key aspects covered are:
- CQRS separates read (queries) and write (commands) operations to different data stores and models. This allows denormalized and optimized read models.
- Event sourcing uses an event store to record the full sequence of events that describe changes to application state. Read models can be rebuilt from stored events.
- Together, CQRS and event sourcing improve scalability, flexibility and auditability by modeling the domain as a sequence of immutable events rather than mutable objects.
** 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!
** 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.