Accueil

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.

Comprendre la différence entre égalité et identité est essentiel dès que l’on commence à utiliser des collections comme Dictionary, HashSet ou même List en .NET. Ce document propose un parcours progressif : d’abord les notions de base (égalité logique vs identité de référence), puis le fonctionnement interne des collections (hash + Equals), avant de montrer comment implémenter correctement l’égalité pour les classes et les structs, utiliser des comparateurs externes et éviter les pièges les plus courants.

Comprendre la différence entre pile (stack) et tas (heap) est essentiel pour bien raisonner sur la mémoire en .NET, surtout quand on manipule types valeur et types référence. Comprendre où sont stockées les données aide à éviter des bugs subtils et à écrire du code plus performant.