Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Le temps c'est de l'argent

2,371 views

Published on

Un modèle pour le temps

Le temps c'est de l'argent

  1. 1. Le temps c’est de l’argent ! Event Sourcing/DDDD/CQRS 13h30 - 16h30 - Salle La Seine A
  2. 2. Le temps c’est de l’argent Event Sourcing / DDDD / CQRS Jérémie Chassaing Architecte / Siriona http://thinkbeforecoding.com @thinkb4coding 27 au 29 mars 2013
  3. 3. Jérémie Chassaing • Fondateur de Hypnotizer et BBCG/PixVillage • Architecte et associé chez Siriona depuis 2008 • Advisory board PnP Mircosoft ‘A CQRS Journey’ • http://thinkbeforecoding.com
  4. 4. Le problème Les outils à notre disposition pour exprimer le temps dans nos systems ? • Timers ? • Threads ? • Locks ? • Clocks ? Très naïfs et peu puissants
  5. 5. Il nous faut un modèle
  6. 6. Qu’est ce que le temps ?
  7. 7. Définition physique du temps • Pas de définition du temps à proprement parler   • Pas de mesure du temps • Mais mesure du temps écoulé  
  8. 8. Définition physique du temps La seconde est la durée de 9 192 631 770 périodes de la radiation correspondant à la transition entre les niveaux hyperfins F=3 et F=4 de l’état fondamental 6S½ de l’atome de césium 133   http://fr.wikipedia.org/wiki/Seconde_(temps)
  9. 9. Définition physique du temps Qu’y a-t-il entre ces transition ?
  10. 10. Définition physique du temps Evènement: Changement d’état ou de contexte, lié à une modification substantielle de la valeur dun paramètre mesurable, dans un intervalle de temps bref à léchelle de lexpérience
  11. 11. Temps ressenti Une journée bien remplie Une journée bien vide
  12. 12. Temps ressenti Une heure n’est pas qu’une heure. C’est un vase rempli de parfums, de sons, de projets et de climats. Marcel Proust, le temps retrouvé
  13. 13. Temps ressenti • Dualité Temps/Evénements • Causalité
  14. 14. Back to business Quel rapport avec le business ?
  15. 15. Back to business Cest le langage du Business. Ecoutez vos Domain Experts…
  16. 16. Back to business Domain Events Le pattern manquant dans Domain Driven Design  
  17. 17. Back to business Make the implicit explicit @gregyoung
  18. 18. Event Sourcing
  19. 19. Event Sourcing Utiliser les événements comme moyen de persistance
  20. 20. Event Sourcing Persistance structurelle – état :
  21. 21. Event Sourcing
  22. 22. Event Sourcing
  23. 23. Event Sourcing Une simple sérialisation/déserialisation des événements Plus d’ORM (Impedance mismatch) Plus de liaison entre le stockage et l’état privé des entités Plus de Getters/Setters sur les entités !
  24. 24. Event Sourcing Stockage en insertion seule • Simple à mettre en place • Excellente montée en charge • Backup/réplication incrémental • Simple a utiliser pour le diagnostique
  25. 25. Event Sourcing - Sauvegarde f(Command, State) → Events Sauver les événements. Tous. Ne jamais modifier ou effacer un événement passé
  26. 26. Event Sourcing - Chargement f(Event, State) → State Par agrégat – en général Pas d’effets de bord
  27. 27. Event Sourcing - Performances • Plus rapide que ce qu’on imagine • Cache des événements • En mémoire • Snapshots • Immutabilité
  28. 28. Event Sourcing - Snapshots Lorsque le nombre d’événements augmente: • Prendre une capture de l’état après l’événement n • Charger la capture, appliquer les événement après n • Peut se faire en parallèle • Peut être reconstruit à partir de zéro
  29. 29. Modélisation
  30. 30. Modélisation L’adresse de l’utilisateur a changée… Vraiment ?
  31. 31. Capturer l’intension
  32. 32. Capturer l’intension Et quand c’est l’heure qui nous intéresse ? • Finance : Ouverture / Fermeture de la bourse • Comptabilité : Clôture d’un exercice • Hôtellerie : Saisons Ces événements ont un sens !
  33. 33. Agrégats Regroupez les Entités et les Valeurs en Agrégats et définissez une frontière autour de chacun. […] Cette organisation simplifie la préservation des invariants entre les objets de l’Agrégat et de l’Agrégat lui-même lors de tout changement d’état. Eric Evans - Domain Driven Design
  34. 34. Agrégats Idéal pour émettre les événements
  35. 35. Agrégats Frontière : Ce qui est a l’intérieur doit être consistant Ce qui est à l’extérieur n’a pas besoin de l’être Eventual Consistency
  36. 36. Event Store
  37. 37. Event Store Name Type EventId unique identifier AggregateId unique identifier Version int Data binary
  38. 38. Event Store Ou un fichier en ajout seul Size Data Check sum Ecriture / Flush
  39. 39. Event Store Utiliser l’Event Store comme une Queue de messages Lecture Ecriture
  40. 40. Intégration ?
  41. 41. Le bonnes pratiques
  42. 42. Architecture 3 tiers Présentation Objets métiers Base de données
  43. 43. Architecture 3 tiers • Chargements à la demande • Prefetch paths ou SELECT 1+N • ORMs • Cache
  44. 44. Architecture 3 tiers Est-ce qu’on ne se complique pas un peu la vie ?
  45. 45. CQRS Commands and QueriesResponsibility Segregation
  46. 46. CQRSDid you mean CARS ?
  47. 47. CQRS – Vue d’ensemble Présentation Com tes ê Requ m ande s Evénements Modèle de Domaine lecture Ecriture seule 48
  48. 48. CQRS – Coté requêtes Vue Vue Requête Réponse Mod èle de vue Modèle de vue persistant persistant 49
  49. 49. CQRS – Coté commandes Vue Commandes Service métier Domaine 50
  50. 50. CQRS - Intégration •Vues SQL •Map reduce sur une base de documents Présentation •Projections d’un flux d’evenements •Toute autre solution adéquate ! Com êtes Requ m ande s Evénements Modèle de Domaine lecture ?? Ecriture seule
  51. 51. Modèle de lecture • Ecouter les événements publiés Présentation • Projeter dans une base requêtable Com êtes Requ m ande s Evénements Modèle de Domaine lecture Events Ecriture seule
  52. 52. On est en droit de se demander…Est-ce vraiment plus simple ?
  53. 53. Deux modèles pour deux besoins Requêtes : Modèle de vue persistant Commandes : Modèle transactionnel •Un model par vue •Un modèle par agrégat •Modèles dénormalisés •Respect strict des limites transactionnelles des agrégats •Suit les relations entre objets/contextes •Pas de relations
  54. 54. Deux modèles pour deux besoins • Choix indépendants des systèmes de persistance • Plus de chargements à la demande (lazy loads) • Donc plus de prefetch path
  55. 55. Choix du stockage en 3 tiers • SQL, parce que c’est ce que tout le monde utilise. • Document Store, c’est sympa, mais on peux pas croiser les données.
  56. 56. Choix du stockage en CQRS Coté requêtes Coté commandes •SQL (avec ORM/Micro ORM ou sans •SQL + ORM ORM) •Document Store •Key Value store •Event Store •Document Store •Là aussi, écoutez vos besoins et vos •Projections en mémoire contraintes ! •Cube OLAP •Ce qui vous convient !
  57. 57. Modèle de lecture jetable Si le modèle de lecture est désynchronisé, ou si le schéma change : Présentation • Effacer • Reconstruire Com êtes Requ m ande s Evénements Modèle de Domaine lecture Events Ecriture seule
  58. 58. Gérer l’obsolescence des données • Versions des agrégats Présentation • Versions des vues Com êtes Requ m ande s • Timestamps Modèle de Evénements Domaine lecture Events Ecriture seule
  59. 59. There are only two hard things in Computer Science: cache invalidation and naming things. Phil Karlton
  60. 60. Plus de cache • On cache les requêtes qui prennent du temps à calculer • Mais quand doit on rafraichir le cache ? • Quand la donnée change !
  61. 61. Montée en charge Coté requêtes : Balance de charge Coté commandes : Sharding
  62. 62. Bounded Contexts Un Bounded Context délimite l’applicabilité d’un modèle particulier pour que les membres de l’équipe aient une compréhension claire […] de ce qui doit être consistant […] Eric Evans - Domain Driven Design Intégration par les événements
  63. 63. Effets à long terme
  64. 64. Quantité Quantité croissante d’information, mais : Augmentation linéaire avec le temps 5,5 Milliards d’événements de 200 octets = 1To = 70€/Mois En insertion seule, donc plus simple à gérer (Backup, partitionnement) Valeur Business réelle
  65. 65. Versionnement des événements Conserver les anciennes versions des événements. Utiliser de préférence un déserialiseur tolérant: • Ajout de champs • Suppression de champs • Changements de noms des champs
  66. 66. Versionnement des événements Lorsque la sémantique change • Créer un nouvel événement
  67. 67. Refactoring La représentation interne de l’état est réellement privée Les changements de représentation sont simplifiés Le snapshots peuvent être reconstruits
  68. 68. Data mining Aucun changement dans le système ne peut avoir lieu sans être enregistré. En rejouant les événements, de nouvelles vues peuvent être dérivées, puis mises à jour en temps réel.
  69. 69. Changement des règles Les règles vont changer ! Les résultats des versions passées des règles ont été capturés dans les événement émis. L’implémentation actuelle n’a pas besoin de connaitre les anciennes règles.
  70. 70. Comment convaincre votre Business ?
  71. 71. Année 1 « Faites quelque chose qui fonctionne ! »
  72. 72. Année 2 – ça décolle
  73. 73. Retrouver ce qui s’est passé à partir d’une suite partielle d’états et de logs: Reverse Engineering
  74. 74. Faites les choses à l’endroit Soyez un ingénieur
  75. 75. Passons à la pratique ! 27 au 29 mars 2013
  76. 76. Uno !
  77. 77. Même couleur…
  78. 78. Ou même valeur
  79. 79. Interuption !
  80. 80. Kickback !

×