Skills à maîtriser

🧡 CRQS

<aside> 📙 CQRS (Command Query Responsibility Segregation) est un modèle architectural qui préconise la séparation des opérations de lecture (queries) et d'écriture (commands) dans les systèmes logiciels.

Il propose d'avoir des modèles de conception distincts pour la modification des données et la récupération des données, permettant une meilleure évolutivité, une optimisation des performances et une conception plus claire des systèmes.

</aside>

Introduction globale CRQS

https://www.youtube.com/watch?v=EkEz3pcLdgY

CRQS simplifié

Clarified CQRS

Avant de décrire les détails du CQRS, nous devons comprendre les 2 principaux moteurs qui le sous-tendent : la collaboration et l’ancienneté.

🤝 La collaboration désigne les circonstances dans lesquelles plusieurs acteurs utiliseront ou modifieront le même ensemble de données – que l’intention des acteurs soit ou non de collaborer entre eux. Il existe souvent des règles qui indiquent quel utilisateur peut effectuer quel type de modification et les modifications qui peuvent avoir été acceptables dans un cas peuvent ne pas être acceptables dans d’autres. Les acteurs peuvent être humains comme les utilisateurs normaux, ou automatisés comme les logiciels.

👴 L’ancienneté fait référence au fait que dans un environnement collaboratif, une fois que les données ont été montrées à un utilisateur, ces mêmes données peuvent avoir été modifiées par un autre acteur – elles sont obsolètes. Presque tous les systèmes qui utilisent un cache servent des données périmées – souvent pour des raisons de performance. Cela signifie que nous ne pouvons pas faire entièrement confiance aux décisions de nos utilisateurs, car elles auraient pu être prises sur la base d’informations obsolètes

<aside> 🔶

• CQRS s’attache à proposer une architecture adaptée aux applications collaboratives multi-utilisateurs. Il prend explicitement en compte des facteurs tels que l’obsolescence et la volatilité des données et exploite ces caractéristiques pour créer des constructions plus simples et plus évolutives.
• On ne peut pas vraiment profiter des avantages de CQRS sans considérer l’interface utilisateur, ce qui lui permet de capturer explicitement l’intention de l’utilisateur. En tenant compte de la validation côté client, les structures de commande peuvent être quelque peu ajustées. Penser à l’ordre dans lequel les commandes et les événements sont traités peut conduire à des modèles de notification qui rendent les erreurs de retour inutiles.
• Bien que l’application du CQRS à un projet donné donne lieu à une base de code plus facile à maintenir et plus performante, cette simplicité et cette évolutivité exigent de comprendre les exigences opérationnelles détaillées et ne sont pas le résultat d’une « pratique exemplaire » technique. Au contraire, nous pouvons voir une pléthore d’approches à des problèmes apparemment similaires utilisées ensemble : lecteurs de données et modèles de domaine, messagerie unidirectionnelle et appels synchrones. </aside>

Pièges et schémas du CQRS

https://www.youtube.com/watch?v=Lw04HRF8ies

Comme de plus en plus de développeurs appliquent la séparation des responsabilités de commande / requête à leurs projets, beaucoup trouvent qu’elle augmente la complexité de leurs systèmes plutôt que de la diminuer, souvent sans aucun avantage de performance non plus. Regardez cette vidéo pour voir où vous devriez, et surtout ne devriez pas utiliser CQRS dans vos projets.