CQRS : préparer des vues de lecture utiles et réparables

La page « mes commandes » doit afficher rapidement un numéro, un total et un statut. Le moteur de recherche a besoin d'un index. Le tableau de bord calcule des ventes par jour. En CQRS, ces usages peuvent disposer de vues de lecture différentes, construites à partir des mêmes décisions métier.

Préparer les données pour la question posée

Le read model, ou modèle de lecture, organise les données pour répondre aux consultations. Une projection est une vue calculée à partir de données sources ; le terme désigne aussi le traitement qui la construit.

Pour une liste de commandes, la projection peut réunir le nom du client, le total et l'état dans une seule ligne. Les données sont alors dénormalisées : certaines sont copiées ou assemblées à l'avance pour faciliter la lecture.

Le modèle de commande reste responsable des décisions. La vue les présente, mais ne doit pas devenir une voie parallèle permettant de contourner leurs règles.

Créer une vue lorsque le besoin le justifie

Un même ensemble de commandes peut alimenter une liste, un index de recherche et un cumul quotidien. Chacun privilégie des consultations différentes.

Il n'est pas nécessaire de créer une projection pour chaque écran. Commencez par les lectures difficiles à servir avec les données existantes. Chaque nouvelle vue ajoute une mise à jour, une surveillance et éventuellement une procédure de réparation.

Savoir d'où vient chaque information

Une projection est plus facile à maintenir si l'on sait reconstruire chacune de ses valeurs. Supposons qu'un défaut ait laissé des commandes au statut « en préparation » alors qu'elles ont été expédiées. Si la source conserve l'état correct, un recalcul peut réparer la liste.

La reconstruction peut partir de l'état courant, d'un historique conservé ou d'une combinaison des deux. Le choix dépend de la question. L'état courant peut suffire pour une liste de commandes ; il ne permet pas nécessairement de retrouver les ventes telles qu'elles étaient comptabilisées chaque jour.

Avant de qualifier une vue de remplaçable, vérifiez que toutes ses informations existent encore ailleurs. Définissez aussi comment continuer à servir les utilisateurs pendant la reconstruction et comment intégrer les changements qui arrivent entre-temps.

Distinguer le recalcul d'une vue des effets externes

L'événement « commande expédiée » peut déclencher deux traitements : actualiser la liste et envoyer un courriel. Le premier prépare une lecture ; le second produit un effet chez un destinataire.

Cette distinction compte lors d'une reprise. Recalculer la liste ne doit pas renvoyer tous les courriels d'expédition. Les réactions externes ont leur propre suivi d'exécution et leur propre gestion des répétitions.

Une outbox permet de conserver l'intention de diffuser après la décision. Le consommateur doit ensuite gérer les erreurs et les doublons, avec un identifiant stable ou un mécanisme d'idempotence adapté.

Le fait qu'un appel survienne après la transaction ne rend pas son échec sans conséquence. Un transporteur non prévenu ou un paiement non confirmé peut bloquer le parcours métier. Il faut rendre cette attente visible et prévoir comment la résoudre.

Décider quelle fraîcheur chaque lecture demande

Si la projection est mise à jour après la transaction, la liste peut rester brièvement en retard. Une commande enregistrée n'y apparaît pas encore, même si son accusé de réception est déjà disponible.

CQRS permet les deux. Une confirmation de règlement et un tableau de bord mensuel n'ont pas forcément la même exigence de fraîcheur.

L'interface peut afficher l'accusé issu de la décision, attendre une version précise de la projection ou indiquer que l'actualisation est en cours. Une date de dernière mise à jour est utile lorsqu'elle aide réellement l'utilisateur à interpréter l'information.

Prévoir la réparation dès la première projection

Pour chaque vue, documentez sa source, le retard acceptable et la méthode de reconstruction. Surveillez les mises à jour en attente et les erreurs persistantes. Une vue réparable en théorie reste difficile à exploiter si personne ne sait détecter qu'elle est fausse.

L'article suivant examine le délai entre décision et lecture, y compris lorsque les deux traitements vivent dans la même application.

Sources

• H. Percival & B. Gregory, Cosmic Python, chap. 12 CQRS.
• M. Fowler, Reporting Database, 2004.
• G. Young, CQRS Documents, 2010.