CQRS De la théorie à la pratique

Séduisante sur le papier, nous avons pu confronter cette architecture à des problématiques bien réelles lors de l'implémentation d'une brique de gestion de stock. Nous vous proposons un retour d'expérience sur les obstacles et leurs solutions (transactionnalité, concurrence, résilience, gestion du synchronisme, ...) ainsi que sur les nombreux avantages et opportunités que nous avons tirés de cette architecture.

Transcript

1. CQRS DE LA THÉORIE À LA PRATIQUE
2. HELLO WORLD !
3. REJOIGNEZ NOUS ! cv@materiel.net
4. CONTEXTE PROJET Refondre la gestion des différents compteurs de stock Retail SAV Magasins ...
5. CONTEXTE : ARCHITECTURE ACTUELLE DU SI SI monolithique en cours de migration Approche WOA Découplage applicatif Broker AMQP Communication orientée événements
6. OBJECTIFS / PROBLÉMATIQUES Sécurisation / fiabilisation Traçabilité Optimisation des calculs de dispo
7. CQRS DID YOU MEAN CARS ?
8. COMMAND QUERY RESPONSIBILITY SEGREGATION Query ≈ read only Command ≈ write only Dans un système classique, 90% de queries pour 10% de commandes SÉPARONS LES !
9. COMMAND QUERY RESPONSIBILITY SEGREGATION
10. COMMAND QUERY RESPONSIBILITY SEGREGATION On peut optimiser ces couches indépendamment
12. EVENT SOURCING Pattern de stockage des données On ne stocke plus l'état final mais les modifications Capacité de reconstruire tous les états intermédiaires Log gratuit et fiable
13. POUR ALLER PLUS LOIN SUR CQRS Agrégats, bounded contexts, projections, eventual consistency, etc. ... https://www.parleys.com/tutorial/distributed-ddd-cqrs-et- eventsourcing-1-3
14. MISE EN OEUVRE DE CQRS
15. MISE EN OEUVRE DE CQRS Instancier l'architecture Définir les agrégats Identifier les commandes et les événements
16. ARCHITECTURE
17. AGRÉGAT C'est l'ensemble des compteurs d'un produit Atomicité naturelle des mouvements de type "Transfert"
18. COMMANDES ET ÉVÉNEMENTS
19. REAL LIFE PROBLEMS
20. PB #1 SYNCHRONISME
21. CAS FONCTIONNEL L'avancement dans le workflow de commande client dépend de la capacité à déstocker Evénement "Déstocke si tu peux"
22. CONFUSION SYNCHRONE / RÉPONSE Commande qui renvoie une réponse ... arf Côté appli cliente, on a besoin de la réponse pour continuer le traitement Besoin d'une réponse, oui ... mais pas forcément synchrone !
23. TRACKING NUMBER Emission par l'application de stock, d'un message de statut après le traitement d'une commande Uniquement si la commande contenait un header de tracking (uuid)
24. ADAPTATION DU WORKFLOW CLIENT
26. PB #2 ACCÈS CONCURRENTIELS
27. PROBLÉMATIQUE Plusieurs commandes client veulent déstocker le même produit
28. RÉSISTE, PROUVE QUE TU EXISTES ! Tout le traitement d'une commande CQRS se fait en RAM Un événement n'a d'existence qu'une fois enregistré dans l'event store Persistence atomique
29. PLAYHEAD Les événements sont numérotés (playhead) Contrainte d'unicité sur le playhead Ce N'est PAS un auto-incrément !
30. DIE AND RETRY En cas de conflit (contrainte d'unicité), on rééxécute la commande
31. WHILE(TRUE) class RetryOnEventConflictAction :
33. ET SI ON TESTAIT UNITAIREMENT NOS ACCÈS CONCURRENTIELS ?
34. D&CO
35. D&CO
36. D&CO
37. PB #3 TRANSACTION
38. PROBLÉMATIQUE Prélever un ensemble de produits pour préparer la commande d'un client Transaction multi-agrégats
39. ZE SOLUTION
40. ZE SOLUTION : ALGORITHME
41. INTERNAL EVENTS Evénements "techniques", internes à l'application Présents dans l'event store Filtrés dans les UI utilisateurs Compteur "réservé"
42. MISE EN OEUVRE
44. https://joind.in/15267