CQRS De la théorie à la pratique

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.

Eeb760f653e2b86489d36c0d7492dcfc?s=128

Nicolas Le Nardou

November 23, 2015
Tweet

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

  11. None
  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

  25. None
  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 :

  32. None
  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

  43. None
  44. https://joind.in/15267