Accueil

Dans un système CQRS, le modèle d’écriture, les modèles de lecture et, le cas échéant, les événements d’Event Sourcing évoluent dans le temps ; il faut donc faire progresser le schéma et les contrats (commands, events, read models) sans casser les agrégats existants, les projections ni les consommateurs externes, en combinant versionning, migrations et reconstructions contrôlées.

La combinaison de CQRS et d’Event Sourcing consiste à séparer lecture et écriture tout en conservant, côté écriture, l’historique complet des événements qui construisent les agrégats ; les mêmes événements alimentent ensuite des projections pour bâtir des modèles de lecture optimisés, avec à la clé auditabilité, rejouabilité et vues multiples au prix d’une complexité accrue.

Dans une architecture CQRS, la consistance entre écriture et lecture n’est pas toujours immédiate : les commandes modifient le modèle d’écriture, puis des événements alimentent des projections qui mettent à jour les modèles de lecture avec un léger décalage. Cette consistance dite éventuelle a un impact fonctionnel, UX et technique qu’il faut comprendre et encadrer.

Comment s’y retrouver dans les différentes versions de .NET :

• .NET Framework (souvent appelé “legacy” aujourd’hui)
• .NET Core
• .NET (5, 6, 7, 8…) – le “.NET unifié”
• .NET Standard (qui n’est pas un runtime, mais une spécification)

Dans le modèle CQRS/DDD, les agrégats jouent un rôle clé en tant que frontières de cohérence et de transaction. Une commande doit cibler un seul agrégat, cela simplifie les invariants métier, la conception des commandes, le schéma de base et le scaling.

La séparation stricte entre lecture et écriture du pattern CQRS facilite le scaling horizontal : au lieu de rendre une seule machine toujours plus puissante (scaling vertical), on ajoute davantage d’instances spécialisées (APIs de lecture, réplicas, caches, bases dédiées) et on répartit la charge entre elles. Cependant, cela nécessite une architecture pensée pour la distribution et la gestion de la consistance éventuelle entre les modèles de lecture et d’écriture ainsi que l’utilisation de mécanismes de messagerie adaptés.

Dans beaucoup d’applications métier, on finit par mélanger dans les mêmes modèles et les mêmes services des besoins très différents : d’un côté des commandes qui modifient l’état, de l’autre des lectures optimisées pour les écrans et les rapports. Le pattern CQRS (Command Query Responsibility Segregation) propose de séparer explicitement écriture et lecture, afin d’avoir un modèle riche et cohérent pour les règles métier, et un modèle de lecture simple, rapide et taillé pour les besoins réels de consultation.

Les records, introduits en C# 9, offrent un moyen idiomatique de modéliser des données avec une égalité par valeur et une immutabilité naturelle, là où les classes traditionnelles restent centrées sur la référence et l’état mutable. Ce document présente également les cas où il est pertinent de les privilégier, notamment pour les DTO, les objets de valeur ou les contrats d’API.