CQRS is an architectural pattern acronym, standing for Command Query Responsibility Segregation. It divides a system’s actions into commands and queries. It is related to CQS, which is Command Query Separation.

Avec autant de buzzwords dans le titre, explicitons le menu :? – Nous commencerons avec une étude des principes du CQRS et la notion de projection pour construire les modèles de données dédiées à la lecture, le tout avec un datastore traditionnel (relationnel). ? – Nous continuerons avec le concept d’état en programmation fonctionnelle, et comment les gérer au sein d’une application tout en respectant le principe d’immutabilité. Et comment ils ont transformé la gestion d’états pour la construction d’interface utilisateur. ? – Dans un troisième temps, nous nous intéresserons aux évènements du domaine-métier dans le Domain Driven Design et comment ceux-ci s’intègrent dans la mécanique de construction des projections. ?– Enfin, nous assemblerons toutes ces notions pour faire apparaitre l’«?event sourcing?» comme modèle de persistance pour nos données. ? – Pour clôturer, nous verrons les erreurs les plus courantes rencontrées lors de l’implémentation d’un modèle en event sourcing. Take away: ?– Utiliser CQRS (sans event-sourcing) pour simplifier la gestion de la persistance dans son application. ?– Comprendre comment gérer des états dans un contexte fonctionnel ? – Gérer facilement les évènements-métier au sein d’une architecture DDD. ?– Savoir comment implémenter correctement un système basé sur l’event sourcing.

Dans un article précédent, nous avons vu comment l’approche DDD, via la définition et l’utilisation d’un Ubiquitous Language et d’un véritable modèle du domaine, peut faciliter la communication entre acteurs projet, aider à l’écriture d’un code plus expressif (et donc plus maintenable), et capable d’adresser la complexité – et les changements – du métier.

Aujourd’hui, nous allons essayer de répondre à certaines questions laissées en suspens par notre première approche de DDD. Comment éviter de multiplier les couches de mapping, sans valeur ajoutée, à différents niveaux de notre architecture ? Comment aller plus loin dans le respect des principes objet tels que l’encapsulation ? Comment faciliter la réalisation d’IHM orientées tâches et activités, présentant des informations vraiment pertinentes pour l’utilisateur ? L’utilisation d’un modèle objet riche est-elle synonyme de dégradation des performances ?