CQRS, qui signifie Command Query Responsibility Segregation, est issu du CQS (Command Query Separation) introduit par Bertrand Meyer dans son ouvrage Object Oriented Software Construction. Meyer soumet le principe que les classes d'une méthode doivent être soit des queries soit des commands.
La différence entre le CQS et le CQRS résulte dans le fait que chaque object CQRS est divisé en deux objets : un pour la requête et un pour la commande.
Une commande est définie comme une méthode qui change un état, alors qu'une requête (query) ne fait que retourner une valeur.
La figure suivante montre l'implémentation basique du pattern CQRS au sein d'une application. Elle entreprend l'échange de messages sous forme de commandes et d’événements. Voyons cela de plus près.
Figure 1: Exemple d'implémentation du pattern CQRS
On voit clairement la séparation des parties lectures et écritures sur la figure précédente : l'utilisateur fait une modification sur sa page, ce qui engendre l'envoie d'une commande. Une fois cette commande terminée, un _event _est publié pour signaler qu'une modification a été apportée.
Voyons cela plus en détail.
Une commande demande à notre application de faire quelque chose. Elle se nomme toujours à l'indicatif, comme par exemple TerminateBusiness ou SendForgottenPasswordEmail. Il est très important de ne pas cantonner ses noms de commandes à des create, change, delete... et vraiment se concentrer sur les use cases (voir le document CQRS Documents en annexe pour plus d'informations).
Une commande capte l'intention de l'utilisateur. Aucun contenu de réponse n'est retourné par le serveur, car comme nous en avons discuté précédemment, seules les queries sont responsables de la récupération de données.
Utiliser différents data stores dans notre application pour la partie command et query semble être une idée plus qu'intéressante. Ainsi, comme nous l'explique très bien Udi Dahan dans son article Clarified CQRS, nous pourrions créer une base de données orientée pour l'interface utilisateur, qui reflétera ce que l'on doit afficher à notre user. On gagnera en performance et en rapidité. Dissocier nos datastores (un pour la modification de données et un pour la lecture) ne nous oblige pas à utiliser de base de données relationnelles pour les deux par exemple. Ainsi, il serait plus judicieux d'utiliser une base de données rapide en lecture pour nos queries.
Mais si nous dissocions nos sources de données, comment les garder synchronisées? En effet, notre read data store n'est pas censé savoir qu'une commande a été envoyée! C'est là où les événements arrivent.
Un événement est une notification de quelque chose qui s'est passé. Tout comme une commande, un événement doit respecter une règle de dénomination précise. En effet, le nom d'un événement doit toujours être au passé, car il faut notifier d'autres parties à l'écoute de notre événement qu'une commande a été complétée. Par exemple, UserRegistered est un nom d'événement valide. Les événements sont traitées par un ou plusieurs consommateurs. C'est donc ces consommateurs qui sont en charge de garder la synchronisation de notre query data store.
Tout comme les commandes, les événements sont des messages. La différence avec une commande se résume à cela : une commande est caractérisée par une action qui doit se produire, contrairement à un événement qui s’est produite.
Les différents avantages concernant cette ségrégation sont nombreux. En voici quelques uns :
L'un des principaux inconvénients est, comme le souligne l'excellent article CQRS Journey, de convaincre les membres de l'équipe que les bénéfices justifient la complexité additionnelle de cette solution.
Le pattern CQRS est à utiliser dans un bounded context (notion clé du Domain Driven Development), ou un composant métier de votre application. En effet, bien que ce modèle ait un impact sur votre code à beaucoup d'endroits, il ne doit pas résider au niveau le plus haut de votre application.
Ce qui est intéressant avec le CQRS est l’event sourcing. Ce dernier peut être utilisé sans l'application du modèle CQRS, mais si on utilise le CQRS, l’event sourcing devient presque une obligation. L’event sourcing consiste à sauvegarder chaque événement qui se déroule dans une base de données et avoir ainsi une sauvegardes des faits. Dans un modèle d’event sourcing, vous ne pouvez pas supprimer ou modifier d’événement, vous ne pouvez qu’en ajouter. Ceci est bénéfique pour notre business et notre SI car nous pouvons savoir à un moment T dans quel état se trouve une commande, un client, ou autre. Egalement, la sauvegarde des événements nous permet de pouvoir reconstruire l’enchaînement de ces derniers et gagner en analyse. L'un des exemples donné par Greg Young dans la conférence Code on the Beach, est le solde d'un compte en banque. Ce dernier peut être considéré comme une colonne dans une table, que l'on vient mettre à jour dès que l'argent est débité ou ajouté sur le compte. L'autre approche est de stocker dans notre base de données l'ensemble des transactions qui ont permis d'arriver à ce solde. Il devient donc plus facile d'être sûr que le montant indiqué est le bon, car nous gardons une trace de tous ces événements, sans pouvoir les changer.
Nous ne rentrerons pas dans les détails sur ce principe dans cet article. Cependant, un très bon approfondissement est disponible dans l'article (disponible en bas de document) CQRS Journey.
CQRS est un pattern simple, qui engendre de fantastiques possibilités. Il consiste à séparer la partie lecture et écriture de votre application, grâce à des queries et des commands.
De nombreux avantages résultent de l'utilisation, notamment en termes de flexibilité et de mise à l'échelle.
L'event sourcing complète le pattern CQRS en sauvegardant l'historique qui détermine l'état actuel de notre application. Ceci est très utile dans des domaines comme la comptabilité, car vous avez ainsi dans votre data store une suite d’événements (par exemple de transactions financières) ne pouvant être modifiés ou supprimés.
CQRS Documents, Greg Young CQRS Journey, Dominic Betts, Julián Domínguez, Grigori Melnik, Fernando Simonazzi, Mani Subramanian Clarified CQRS, Udi Dahan CQRS and Event Sourcing - Code on the Beach 2014, Greg Young
Auteur(s)
Romain Pierlot
Diplomé de l'ISEP en 2013, Romain Pierlot est ingénieur en Etudes et Développement chez Eleven Labs, avec qui il s'amuse comme un petit fou.
Vous souhaitez en savoir plus sur le sujet ?
Organisons un échange !
Notre équipe d'experts répond à toutes vos questions.
Nous contacterDécouvrez nos autres contenus dans le même thème
Après avoir développé une nouvelle fonctionnalité pour votre application, le code est revue par l'équipe. Pour que le relecteur puisse mieux se rendre compte des changements, il est intéressant de mettre les changements à disposition dans un environnement de revue. Cet article va expliquer les étapes pour le faire avec Gitlab CI.
Dans le domaine de la data, la qualité de la donnée est primordiale. Pour s'en assurer, plusieurs moyens existent, et nous allons nous attarder dans cet article sur l'un d'entre eux : tester unitairement avec Pytest.
Le domaine de la data est présent dans le quotidien de chacun : la majorité de nos actions peut être traduite en données. Le volume croissant de ces données exploitables a un nom : "Big Data". Dans cet article, nous verrons comment exploiter ce "Big data" à l'aide du framework Apache Spark.