[Devoxx FR 2012] – CQRS


Dernier jour, une des dernières conférences de Devoxx, l’émotion retombe, et pourtant c’est une très bonne surprise que cette présentation d’une architecture un peu particulière par Jérémie Chassaing : CQRS.

Command / Query Responsability Segregation, ou comment s’absoudre des problèmes typiques des architectures n-tiers en séparant la chaîne d’écriture de la chaîne de lecture. En effet, avec l’architecture n-tiers et l’accroissement du volume de données, viennent les problèmes de cache ainsi que de lazy-loading. L’idée de CQRS part d’un constat simple, à savoir qu’une donnée présente dans une base de donnée à destination d’un affichage va subir de multiples (et inutiles) transformations entre son stockage et sa visualisation par l’utilisateur.

Ainsi, le schéma théorique simple que nous connaissons :
null
devient en pratique :
null

Ce que propose CQRS pour résoudre les problèmes mentionnés ci-dessus, c’est tout d’abord de séparer ces données en agrégats, en suivant la méthode du DDD (Domaine Driven Development). Ainsi ces agrégats vont pouvoir être mis à jour indépendamment les uns des autres, de manière à réduire le volume de données en jeu à chaque opération de l’utilisateur.

Par la suite, la mise en place de l’architecture CQRS se résume par ce schéma :
null

Cette représentation est bien composée d’un côté, d’une section en lecture seule qui répond rapidement aux requêtes en maintenant le modèle de données toujours disponible rapidement, et d’une seconde partie que l’on peut concevoir plus lente, transactionnelle et uniquement reliée à la première par l’intermédiaire d’évènements de mise à jour. Ces évènements contenant l’information modifiée pour un unique agrégat, il provoque une mise à jour rapide au niveau du modèle de données utilisé pour la lecture.

Les problématiques sont alors distincts :

  • Tenue en charge de la partie lecture, à laquelle on peut répondre par le load-balancing sur plusieurs noeuds.
  • Stabilité de la partie écriture, rendue possible par l’aspect transactionnel, améliorable avec un système de commandes asynchrones (event queue). La tenue en charge quand à elle peut être gérée avec des techniques telles que celle du sharding

A ce stade, miracle, il n’est plus nécessaire d’utiliser le lazy-loading, car les agrégats sont suffisamment petits, le cache n’est plus utile car le modèle de données, maintenu côté lecture grâce aux évènements, contient avec exactitude les données stockées par la partie écriture.

Une astuce proposée par Jérémie Chassaing pour passer simplement d’une architecture n-tiers à celle-ci est de mettre en place des vues en base de données correspondantes aux différents écrans de l’application. Ainsi le modèle “physique” utilisé par la partie commande est décorrélé du modèle de vue, utilisé par la partie requête.

Cette architecture répond au besoin d’une application au fontionnel lourd (partie commande rendue lente par de nombreux calculs, des connexions à des systèmes tiers, etc…) et qui pourtant souhaite proposer une IHM rapide et cohérente. Elle n’est donc pas adaptée aux simples CRUD pour lesquels une architecture plus classique suffit largement.

Quelques liens :

Nombre de vue : 44

AJOUTER UN COMMENTAIRE