Nous allons essayer de voir ici ce qui se passe derrière le code de nos projets dans une approche traditionnelle et voir les problèmes que cela engendre.
On se rends compte que tous les problèmes de consistence arrivent sur les data que nous voulons rajouter dans un système synchrone, malgré le fait d’utiliser toutes les garanties au niveau du code ou des bases relationnelles comme sqlserveur.
Mais nous travaillons dans un monde full objet, de manière collaborative, et pour garantir les accès nous utilisons en général de l’optismistic concurrency.
Prenons un exemple:
Ce code est propre et respecte toutes les bonnes règles de développement. Mais dans ce cas que se passe t il si 2 utilisateurs utilisent le même compte au même moment?
En refactorisant le code comme ceci:
Il faut voir un pb supplémentaire qui est que ce type de calcul se fait en général offline: pour avoir une réduction revenez demain (quand j’aurais fait mes calculs de la nuit…)
Au niveau des dbs, entre en jeux, la transaction et des problèmes d’isolation. Ce qui se traduit par un un fonctionnement acid normal pour une base:
On voit que le parallélisme est un pb complexe et que ces impressions de transactions safe ne sont qu’une illusion. Notre code n’est pas forcément correctement isolé pour le parallélisme!
Il faut prendre ça en compte dans notre code. C’est pour ça que l’aggregate root de notre domain model doit être consistant et prendre tout ça en compte (voir par ex le site defectbydesign.org).
Ce qu’on va faire dans le design c’est principalement d’anticiper les choses dont on a besoin au niveau de notre aggregate root. Les bases de donnes sont consistantes au niveau d’une ligne donc ici nous n’auront plus de problème vu que l’on a preparé les choses pour une lecture unique. Il faut voir ça comme une vision du temps différente. Par ex si j’ajoute des commandes qui me donnent pour une dureede7 jours une promo et que je veux calculer à un moment t la promo, je dois parcourir tous les ordres avec les dates d’expiration. Si dans une autre sens, j’anticipe et prévoir de décrémenter le total de mes ordres du montant ajoute+ 7j, à tout moment je n’aurai qu’à lire le montant exact de ma réduction.
Pour voir cette problématique, il faut se pencher sur le concept des sagas
Ceci est possible avec un bus de messages qui le prend en charge comme nservicebus.
L’intérêt de cette méthode aussi, est qu’un système à base de messages est plus facile à tester, puisque l’on peut jouer avec le temps des messages et pousser ce que l’on veut quand on veut.
On voit au niveau du code que d’anticiper la consistence au niveau de l’aggregate root ne prend pas plus de lignes de code qu’avant mais que l’on a maintenant quelque chose de consistant naturellement, et ce quel que soit la base utilisée pour la présidence.
real aggregate roots are consistency boundaries
Designer le système en prenant la contrainte de temps depuis le début, quel que soit le bus, est obligatoire pour avoir de la consistence. C’est une ma manière de penser qui n’est pas directement liée au cqrs mais bien fortement liée au DDD. Beaucoup de gens travaillent avec des modèles comme si les choses en parallèles n’existaient pas, il faut revoir son modèle.
Notes: même en connaissant DDD et cqrs, la mise en avant de ce mode de traitement m’a bien plus car je ne suis pas non plus un expert du sujet. Les points soulevés sont importants et les solutions élégantes. Maintenant ce n’est pas un problème que l’on a forcément tus les jours non plus ni sur n’importe quel projet.
Dans tous les cas, ce que l’on peut retenir en priorité, c’est que si l’on peut préparer la donnée au niveau de son aggregate root en ayant besoin de lire l’info que sur une ligne/un élément, on garanti beaucoup plus facilement l’intégrité.
