CQRS et Event Sourcing sont des patterns puissants souvent mentionnés ensemble. Comprendre ce qu'ils apportent séparément aide à éviter le sur-engineering d'une adoption systématique.
CQRS (Command Query Responsibility Segregation) sépare les opérations de lecture (queries) des opérations d'écriture (commands) en utilisant des modèles distincts. L'avantage principal est l'optimisation indépendante de chaque côté : le modèle de lecture peut être dénormalisé pour les performances, le modèle d'écriture peut être rigoureusement cohérent. Sur des systèmes avec des ratios lecture/écriture très asymétriques (type e-commerce : beaucoup de lectures, peu d'écritures), les gains de performance sont significatifs.
Event Sourcing va plus loin : au lieu de stocker l'état courant d'une entité, on stocke la séquence d'événements qui ont conduit à cet état. Une commande e-commerce n'a pas un champ status qui change — elle a une liste d'événements : OrderCreated, PaymentReceived, ItemsShipped. L'état courant est recalculé en rejouant ces événements. Cela apporte un audit trail natif, la possibilité de time-travel debugging, et une traçabilité totale des changements.
Ces patterns sont souvent présentés ensemble car CQRS facilite naturellement l'implémentation d'Event Sourcing. Mais ils sont indépendants et chacun peut être adopté seul. La mise en garde habituelle s'applique : la complexité opérationnelle est élevée. La cohérence éventuelle, la gestion de la migration des schémas d'événements, le stockage d'un event store efficace — ce sont des défis réels. À réserver aux domaines à forte valeur métier où l'auditabilité et la scalabilité justifient l'investissement.
→ À lire aussi : Architecture event-driven · Domain-Driven Design