lundi 7 juillet 2014

CQRS

(original post in French is below)

These days I'm really interested in Domain-driven Design. It makes me aware of tons of good practices on software design that I instill step by step on my current assignment at work. At the border of DDD I learnt about the existence of the CQRS pattern, for Command and Query Responsibility Segregation. It simply propose to split reading (query) and writing (command) contexts. This detail allows amazing software architecture possibilities!

  • we can scale the former independently from the latter as there are often more reading processes than writing processes,
  • we can make radical choices for persistence layer and take a particular technology per data usage (writing usage, retrieval through GUI, data analysis,…).

Other concepts are kicking in while implementing CQRS:

  • event sourcing: what if we store the commands that are sent to the system instead of its state, using the same idea than Oracle redo logs? It allows to re-run the whole set off operation that lead from state A to state B whatever is the technology used for storing data. The commands (events) are centralized in a message queue which enable to manage scalability and concurrent access like a boss.
  • task based UI: the end of the UI that propose to modify an object through a huge form and a submit button. The UI provides business actions defining our commands. We can imagine that the UI possess its own data store on client side. The commands queue can be sent to the server whenever we want so we have an offline mode for not much.

So, interesting stuff in computer programming world. To know a bit more I recommend this podcast (for French speakers, sorry) and this video.


Je m'intéresse beaucoup en ce moment au Domain-driven Design. Cette thématique m'ouvre les yeux sur des tonnes de bonnes pratiques de design logiciel que je mets petit à petit en pratique sur mon projet. En marge du DDD, j'ai appris l'existence du pattern CQRS, pour Command and Query Responsibility Segregation. Ce pattern propose simplement de séparer les contexte de lecture (query) et d'écriture (command). Ce détail permet des possibilités gigantesque d'architecture !

  • permet d'ajuster le scaling pour l'un ou l'autre : il y a souvent plus de lecteurs que d'écrivain,
  • permet de faire des choix radicaux en terme de persistance : choisir une techno spécifique par utilisation des données (écriture, lecture via UI, requêtes analytiques, etc...).

D'autres concept entrent en jeu dans l'implémentation de ce pattern :

  • event sourcing : et si on ne stockait pas l'état du système mais les commandes qui lui sont envoyées, à la manière des redo logs d'Oracle ? Ceci permet de rejouer l'ensemble des opérations menant d'un état A à un état B sur n'importe quel système de stockage. L'ensemble des commandes est centralisé dans une queue de message, ce qui permet de gérer la scalabilité et la concurrence d'accès like a boss.
  • task based UI : fini les UI qui proposent de modifier un objet avec un gros formulaire et un bouton submit. L'UI propose des actes métiers définisant nos commandes. On peut imaginer que l'UI possède son propre système de stockage au niveau du client. Les commandes peuvent être envoyées au serveur de traitement quand on le souhaite : et hop, on a un mode déconnecté pour pas cher.

Bref, un truc intéressant dans le monde de l'informatique. Pour en savoir plus, je vous recommande cet épisode des Cast Codeurs en français. Tout à l'heure, j'ai également maté le début de cette vidéo sur le sujet.