CQRS et la projection : décider d'un côté, restituer de l'autre

Dans la plupart des applications, un même modèle sert à écrire et à lire : les mêmes tables, les mêmes objets. CQRS sépare non pas « la lecture de l'écriture », mais deux responsabilités qu'on confond : décider (les commandes) et restituer (les requêtes). La nuance change tout.

« CQRS » veut dire Command Query Responsibility Segregation : séparer la responsabilité des commandes — celles qui décident — de celle des requêtes — celles qui restituent. Une commande, c'est une décision : enregistrer un achat, vérifier qu'un solde reste positif, garantir qu'on ne vend pas deux fois le dernier billet. C'est là que vivent les règles métier. Une requête, c'est une restitution : la liste des commandes, un tableau de bord, une fiche produit — aucune règle à faire respecter, juste de la donnée à présenter. On croit séparer « la lecture de l'écriture » ; on sépare en réalité le modèle qui fait autorité sur le domaine de celui qui n'existe que pour afficher.

Write model, read model

D'un côté, le write model : la source de vérité. Il porte les règles métier, valide les décisions, et reste normalisé — chaque fait à un seul endroit. C'est lui qui dit non quand une opération violerait un invariant.

De l'autre, le read model : une représentation taillée pour la lecture. Souvent dénormalisé — les données déjà assemblées, prêtes à afficher, dupliquées s'il le faut pour épargner des jointures. La page « mes commandes » n'a pas besoin de rejouer la logique métier ; elle a besoin d'une ligne par commande, vite.

La projection

Reste à relier les deux. Le read model n'est pas saisi à la main : il est construit à partir du write model. C'est cela, une projection — une vue dérivée, recalculée depuis la source de vérité. À chaque changement côté écriture (une commande créée, payée, expédiée), la projection met à jour le read model correspondant.

Deux propriétés en découlent, et ce sont exactement celles qui reviennent dès qu'on parle de systèmes distribués :

• la projection est propagée en différé : le read model peut donc être en retard de quelques instants sur le write model — c'est la « cohérence éventuelle » ;
• la projection est reconstructible : puisque le read model dérive de la source, on peut le jeter et le recalculer entièrement. Une projection n'est jamais une vérité à protéger, c'est un dérivé réparable.

Un exemple. Une commande e-commerce. Le write model, c'est l'agrégat Commande : il valide (article en stock, paiement accepté), il décide, il fait référence. Le read model, c'est une table « résumé de commande » dénormalisée : numéro, client, total, statut — tout prêt pour la page liste et le tableau de bord. Quand la commande passe à « expédiée », une projection met à jour la ligne de résumé. Et si un bug corrompt ce résumé, on le reconstruit en le reprojetant depuis le write model — qui, lui, fait toujours foi.

Quand l'utiliser, et quand s'en passer

CQRS est un choix, pas une fatalité — il ne s'installe pas tout seul quand un projet grossit. Il se justifie quand décider devient une vraie affaire : des règles métier à protéger côté commandes, et des lectures nombreuses et variées de l'autre. Pour un CRUD simple où décider se résume à enregistrer un formulaire, séparer les deux modèles ajoute de la machinerie sans contrepartie. La question n'est pas « est-ce bien ? » mais « est-ce que mon domaine a, d'un côté, de vraies décisions à protéger et, de l'autre, des lectures assez différentes pour mériter deux modèles ? ».

Ces trois mots — write model, read model, projection — ouvrent une bonne partie de l'architecture moderne. Une fois qu'on les a, des phrases qui paraissaient ésotériques deviennent limpides : « la projection est en retard », « on reconstruit la vue depuis la source de vérité », « la lecture sert un état possiblement obsolète ». C'est, mot pour mot, ce que raconte la série sur le théorème CAP.