Le temps c'est de l'argent

1,124
-1

Published on

Un modèle pour le temps

2 Comments
5 Likes
Statistics
Notes
No Downloads
Views
Total Views
1,124
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
24
Comments
2
Likes
5
Embeds 0
No embeds

No notes for slide
  • Commentaires
  • Pas de définition du temps à proprement parler.   Pas de mesure du temps Mais mesure du temps écoulé.
  • 13 e Conférence générale des poids et mesures (1967) Unité de base du système international
  • Il nous manque encore une notion pour parler de tout ca..
  • Une journée bien remplie Une journée vide Elles durent une journée, mais seuls les evenements qui nous changent restent Enfants, tout est nouveau, tout nous change Adulte, tout est habituel, moins de changements… le temps passe plus vite car moins d’événements significatifs
  • Peut on parler de temps s’il n’y a pas d’événements ?
  • Physique Newtonniene: Temps linéaire et non cyclique Physique Relativister: Une particule ne peut se déplacer plus vite que la lumière dans le vide Physique Quantique: Opérateur Hamiltonien de l’équation de Shrödinger Le temps découle des événements pas causalité
  • Quand un utilisateur a annulé sa commande… Quand les prix sont passés sous le seuil…
  • Qcon london Aout 2009 What I’ve learned about DDD since the book Les building blocks ont été trop mis en avant
  • Technique qui exploite ce modele pour les applications nécessitant une prise en compte serieuse du temps
  • -> Pas de suppressions
  • Compensations
  • L’utilisateur déménage, ou on corrige son adresse.. Très différent ! Interface des fournisseurs ADSL… Task base UI Eviter de faire 1 evenement par propriété qui change…
  • Cependant, sur quoi s’appliquent ces evenements ?
  • Exemple des voitures
  • Raconter un aller retour des donnée. Les relations pour l’affichage mènent aux lazy loads Ce sont ceux qui font les bases de données qui ont vendu le modèle
  • Juste après… plus de cache
  • Sharding: grace aux propriétés des aggrégats
  • Example: Changement de TVA
  • 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 !

    ×