SlideShare une entreprise Scribd logo

DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant

DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant

1  sur  77
Télécharger pour lire hors ligne
DDD, CQRS et Event Sourcing :
quand coder propre n'est pas
sufsant
Joseph Pachod
https://twitter.com/joeclueless
Coder propre nécessaire mais...
Coder propre : plein de règles applicables
localement, bien moins à l'échelle d'une application.
Capture du métier ?
Comment capturer le métier ?
● couches techniques souvent plus simples à
organiser
● Conservation des connaissances métier de façon
pérenne ?
DDD
Domain-Driven Design
(Conception dirigée par le domaine)
Pas un framework ni une méthodo, plutôt une
approche
Eric Evans
Domain-Driven Design: Tackling Complexity in the
Heart of Software – 2004
What I've learned about DDD since the book – 2009
Livre clé, aujourd'hui un peu dépassé sur certains
points (dixit Evans lui même)
Auteur a longuement pratiqué son approche avant
que Martin Fowler ne vienne travailler avec lui et le
convainque d'écrire un livre et communiquer sur celle
ci, nommée Domain Driven Design à l'occasion.
Pré requis
Travail itératif
Accès direct aux experts du domaine
Métier complexe

Recommandé

Domain Driven Design (DDD)
Domain Driven Design (DDD)Domain Driven Design (DDD)
Domain Driven Design (DDD)Guillaume Collic
 
Rapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPRapport exposé eXtreme Programming XP
Rapport exposé eXtreme Programming XPSarah
 
Solid principles, Design Patterns, and Domain Driven Design
Solid principles, Design Patterns, and Domain Driven DesignSolid principles, Design Patterns, and Domain Driven Design
Solid principles, Design Patterns, and Domain Driven DesignIrwansyah Irwansyah
 
Le Domain Driven Design, comment bien démarrer ?
Le Domain Driven Design, comment bien démarrer ?Le Domain Driven Design, comment bien démarrer ?
Le Domain Driven Design, comment bien démarrer ?Maxime Sanglan-Charlier
 
Eugenio Mauri presentation TOGAF
Eugenio Mauri presentation TOGAFEugenio Mauri presentation TOGAF
Eugenio Mauri presentation TOGAFEugenio Mauri
 
Ontologie concept applications
Ontologie concept applicationsOntologie concept applications
Ontologie concept applicationsbenouini rachid
 
Devoxx : being productive with JHipster
Devoxx : being productive with JHipsterDevoxx : being productive with JHipster
Devoxx : being productive with JHipsterJulien Dubois
 

Contenu connexe

Tendances

Ontology concept et applications
Ontology concept et applicationsOntology concept et applications
Ontology concept et applicationsbenouini rachid
 
Spark, ou comment traiter des données à la vitesse de l'éclair
Spark, ou comment traiter des données à la vitesse de l'éclairSpark, ou comment traiter des données à la vitesse de l'éclair
Spark, ou comment traiter des données à la vitesse de l'éclairAlexis Seigneurin
 
Chp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation MultidimensionnelleChp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation MultidimensionnelleLilia Sfaxi
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisJason De Oliveira
 
Présentation Gestion Electronique de Documents (Alfresco)
Présentation Gestion Electronique de Documents (Alfresco)Présentation Gestion Electronique de Documents (Alfresco)
Présentation Gestion Electronique de Documents (Alfresco)Jibril Touzi
 
Chp5 - Les outils CASE
Chp5 - Les outils CASEChp5 - Les outils CASE
Chp5 - Les outils CASELilia Sfaxi
 
cahier des charges
cahier des chargescahier des charges
cahier des chargesamine niba
 
Presentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesPresentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesStéphane Di Cioccio
 
La mise en œuvre de l’archivage numérique courant et intermédiaire au CD 34 :...
La mise en œuvre de l’archivage numérique courant et intermédiaire au CD 34 :...La mise en œuvre de l’archivage numérique courant et intermédiaire au CD 34 :...
La mise en œuvre de l’archivage numérique courant et intermédiaire au CD 34 :...AssociationAF
 
Modélisation de données pour MongoDB
Modélisation de données pour MongoDBModélisation de données pour MongoDB
Modélisation de données pour MongoDBMongoDB
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - IntroductionBlandine Larbret
 
Les 4 phases du management de projet
Les 4 phases du management de projetLes 4 phases du management de projet
Les 4 phases du management de projetAntonin GAUNAND
 
comment rédiger une expression de besoins
comment rédiger une expression de besoinscomment rédiger une expression de besoins
comment rédiger une expression de besoinsAlexandre Zermati
 
Référentiel d'architecture avec TOGAF
Référentiel d'architecture avec TOGAFRéférentiel d'architecture avec TOGAF
Référentiel d'architecture avec TOGAFPierre-Xavier Fouillé
 
Tp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPELTp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPELLilia Sfaxi
 
Méthode de conduite de projet
Méthode de conduite de projetMéthode de conduite de projet
Méthode de conduite de projetDavid Gana
 

Tendances (20)

Ontology concept et applications
Ontology concept et applicationsOntology concept et applications
Ontology concept et applications
 
Spark, ou comment traiter des données à la vitesse de l'éclair
Spark, ou comment traiter des données à la vitesse de l'éclairSpark, ou comment traiter des données à la vitesse de l'éclair
Spark, ou comment traiter des données à la vitesse de l'éclair
 
Chp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation MultidimensionnelleChp3 - Modélisation Multidimensionnelle
Chp3 - Modélisation Multidimensionnelle
 
noSQL
noSQLnoSQL
noSQL
 
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in ParisKeynote DevOps - Microsoft DevOps Day 2014 in Paris
Keynote DevOps - Microsoft DevOps Day 2014 in Paris
 
Présentation Gestion Electronique de Documents (Alfresco)
Présentation Gestion Electronique de Documents (Alfresco)Présentation Gestion Electronique de Documents (Alfresco)
Présentation Gestion Electronique de Documents (Alfresco)
 
Introduction à Node.js
Introduction à Node.js Introduction à Node.js
Introduction à Node.js
 
Chp5 - Les outils CASE
Chp5 - Les outils CASEChp5 - Les outils CASE
Chp5 - Les outils CASE
 
02 Introduction aux SI 2018
02 Introduction aux SI 201802 Introduction aux SI 2018
02 Introduction aux SI 2018
 
cahier des charges
cahier des chargescahier des charges
cahier des charges
 
Presentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequencesPresentation DevOps : enjeux , objectifs, consequences
Presentation DevOps : enjeux , objectifs, consequences
 
La mise en œuvre de l’archivage numérique courant et intermédiaire au CD 34 :...
La mise en œuvre de l’archivage numérique courant et intermédiaire au CD 34 :...La mise en œuvre de l’archivage numérique courant et intermédiaire au CD 34 :...
La mise en œuvre de l’archivage numérique courant et intermédiaire au CD 34 :...
 
Modélisation de données pour MongoDB
Modélisation de données pour MongoDBModélisation de données pour MongoDB
Modélisation de données pour MongoDB
 
Domain Driven Design
Domain Driven DesignDomain Driven Design
Domain Driven Design
 
Hadoop Hbase - Introduction
Hadoop Hbase - IntroductionHadoop Hbase - Introduction
Hadoop Hbase - Introduction
 
Les 4 phases du management de projet
Les 4 phases du management de projetLes 4 phases du management de projet
Les 4 phases du management de projet
 
comment rédiger une expression de besoins
comment rédiger une expression de besoinscomment rédiger une expression de besoins
comment rédiger une expression de besoins
 
Référentiel d'architecture avec TOGAF
Référentiel d'architecture avec TOGAFRéférentiel d'architecture avec TOGAF
Référentiel d'architecture avec TOGAF
 
Tp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPELTp3 - Application SOA avec BPEL
Tp3 - Application SOA avec BPEL
 
Méthode de conduite de projet
Méthode de conduite de projetMéthode de conduite de projet
Méthode de conduite de projet
 

Similaire à DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant

Domain-Specific Languages avec Groovy
Domain-Specific Languages avec GroovyDomain-Specific Languages avec Groovy
Domain-Specific Languages avec GroovyGuillaume Laforge
 
Programmation orientee aspect 201401 - Ensim
Programmation orientee aspect 201401 - EnsimProgrammation orientee aspect 201401 - Ensim
Programmation orientee aspect 201401 - EnsimLaurent Broudoux
 
Comment travailler avec les logiciels Open Source
Comment travailler avec les logiciels Open SourceComment travailler avec les logiciels Open Source
Comment travailler avec les logiciels Open SourceChristian Charreyre
 
Introduction au Domain Driven Design
Introduction au Domain Driven DesignIntroduction au Domain Driven Design
Introduction au Domain Driven DesignDNG Consulting
 
DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?Ludovic Piot
 
Architecture microservices avec docker
Architecture microservices avec dockerArchitecture microservices avec docker
Architecture microservices avec dockergcatt
 
Devops Introduction au mouvement
Devops Introduction au mouvementDevops Introduction au mouvement
Devops Introduction au mouvementUlrich VACHON
 
L'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOpsL'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOpsGeorgeot Cédric
 
Réutilisation de code entre windows 8 et windows phone 8
Réutilisation de code entre windows 8 et windows phone 8Réutilisation de code entre windows 8 et windows phone 8
Réutilisation de code entre windows 8 et windows phone 8Arnaud Auroux
 
Adama Coulibaly.pptx
Adama Coulibaly.pptxAdama Coulibaly.pptx
Adama Coulibaly.pptxIdrissaDembl
 
La valeur de Docker pour les équipes de développement et accélérateur dans le...
La valeur de Docker pour les équipes de développement et accélérateur dans le...La valeur de Docker pour les équipes de développement et accélérateur dans le...
La valeur de Docker pour les équipes de développement et accélérateur dans le...Laurent Goujon
 
Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011Jean-Marc Fontaine
 
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Jean-Pierre Lambert
 
Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !Société ELOSI
 
La Meta-programmation
La Meta-programmation La Meta-programmation
La Meta-programmation Microsoft
 
Cours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfCours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfboulonvert
 

Similaire à DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant (20)

Domain-Specific Languages avec Groovy
Domain-Specific Languages avec GroovyDomain-Specific Languages avec Groovy
Domain-Specific Languages avec Groovy
 
Tutoriel java
Tutoriel javaTutoriel java
Tutoriel java
 
Design patterns
Design patternsDesign patterns
Design patterns
 
Design patterns
Design patternsDesign patterns
Design patterns
 
Programmation orientee aspect 201401 - Ensim
Programmation orientee aspect 201401 - EnsimProgrammation orientee aspect 201401 - Ensim
Programmation orientee aspect 201401 - Ensim
 
Comment travailler avec les logiciels Open Source
Comment travailler avec les logiciels Open SourceComment travailler avec les logiciels Open Source
Comment travailler avec les logiciels Open Source
 
Introduction au Domain Driven Design
Introduction au Domain Driven DesignIntroduction au Domain Driven Design
Introduction au Domain Driven Design
 
DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?DevOps, quel futur pour les Ops ?
DevOps, quel futur pour les Ops ?
 
Architecture microservices avec docker
Architecture microservices avec dockerArchitecture microservices avec docker
Architecture microservices avec docker
 
Devops Introduction au mouvement
Devops Introduction au mouvementDevops Introduction au mouvement
Devops Introduction au mouvement
 
L'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOpsL'évolution vers le (Dev)NoOps
L'évolution vers le (Dev)NoOps
 
Réutilisation de code entre windows 8 et windows phone 8
Réutilisation de code entre windows 8 et windows phone 8Réutilisation de code entre windows 8 et windows phone 8
Réutilisation de code entre windows 8 et windows phone 8
 
Multi-Threading Et Cocoa
Multi-Threading Et CocoaMulti-Threading Et Cocoa
Multi-Threading Et Cocoa
 
Adama Coulibaly.pptx
Adama Coulibaly.pptxAdama Coulibaly.pptx
Adama Coulibaly.pptx
 
La valeur de Docker pour les équipes de développement et accélérateur dans le...
La valeur de Docker pour les équipes de développement et accélérateur dans le...La valeur de Docker pour les équipes de développement et accélérateur dans le...
La valeur de Docker pour les équipes de développement et accélérateur dans le...
 
Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011Industrialiser PHP - Open World Forum 2011
Industrialiser PHP - Open World Forum 2011
 
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)Introduction aux spécifications exécutables (dit aussi atdd, bdd)
Introduction aux spécifications exécutables (dit aussi atdd, bdd)
 
Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !Devoxx 2017 : toutes les actualités technologiques à surveiller !
Devoxx 2017 : toutes les actualités technologiques à surveiller !
 
La Meta-programmation
La Meta-programmation La Meta-programmation
La Meta-programmation
 
Cours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdfCours Devops Sparks.pptx.pdf
Cours Devops Sparks.pptx.pdf
 

DDD, CQRS et Event Sourcing : quand coder propre n'est plus suffisant

  • 1. DDD, CQRS et Event Sourcing : quand coder propre n'est pas sufsant Joseph Pachod https://twitter.com/joeclueless
  • 2. Coder propre nécessaire mais... Coder propre : plein de règles applicables localement, bien moins à l'échelle d'une application.
  • 3. Capture du métier ? Comment capturer le métier ? ● couches techniques souvent plus simples à organiser ● Conservation des connaissances métier de façon pérenne ?
  • 4. DDD Domain-Driven Design (Conception dirigée par le domaine) Pas un framework ni une méthodo, plutôt une approche
  • 5. Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software – 2004 What I've learned about DDD since the book – 2009 Livre clé, aujourd'hui un peu dépassé sur certains points (dixit Evans lui même) Auteur a longuement pratiqué son approche avant que Martin Fowler ne vienne travailler avec lui et le convainque d'écrire un livre et communiquer sur celle ci, nommée Domain Driven Design à l'occasion.
  • 6. Pré requis Travail itératif Accès direct aux experts du domaine Métier complexe
  • 7. Ubiquitous Language (Langage omniprésent) Langage des experts du domaine, utilisé également par les développeurs et dans le modèle, c'est à dire le code. Nécessité de bien se comprendre et de reporter cela jusque dans le code. Le modèle doit communiquer comment fonctionne le domaine, afn de faciliter sa compréhension et sa mise en œuvre.
  • 8. A utiliser tout le temps Rendre l'implicite explicite Dans le code et à l'oral ● Précision du langage ● Capacité à détecter les problèmes Si quelque chose sonne faux dans le langage omniprésent : revoir le vocabulaire et refactorer Rendre l'implicite explicite - faire ressortir les concepts - écouter le langage des utilisateurs experts (mots succincts pour des choses compliquées, correction du vocable des développeurs, éclairs de compréhension avec certains mots) - examiner les maladresses - réféchir sur les contradictions - apprendre le domaine fonctionnel
  • 9. Hands on modelers (Concepteurs les mains dans le code) Le code est primordial pour valider le modèle et les refactoring, il faut que ceux qui modélisent touchent également au code. Ce dernier fait alors ofce de garde fou, rappelant les réalités du modèle, mais sert également à valider les changements. Garanti la pérennité du modèle, qui ne peut pas diverger du code s'il est directement dans le code.
  • 10. Mise en œuvre "tactique" Eric Evans parle « tactique » Mise en œuvre reprise parfois au pied de la lettre, notamment en .Net
  • 11. Modélisation "tactique" au choix de l'équipe Cf par exemple «  Functional and Reactive Domain Modeling » (voir le livre du même nom pour plus de détails).
  • 13. Code métier en un seul endroit
  • 14. Refactoring continu Le refactoring continu assure que le code refète toujours bien le langage omniprésent. Qui plus est, le refactoring améliore la proximité avec le code, permettant de mieux en saisir le modèle et les nuances. Avec le temps, il arrive ce qu'Eric Evans nomme des percées : des éclairs de compréhension du domaine qui se répercutent par des changements signifcatifs du modèle. Bien souvent des aspects pénibles du modèle sont alors supprimés et d'anciennes incompréhensions ou incohérences s'expliquent.
  • 15. Préserver l'intégrité du modèle quand la complexité croît Même termes, usages diférents, modélisation variant à terme Cohésion et unicité du langage omniprésent mis en péril dès que le nombre d'interlocuteurs augmente Coût de la coordination Un modèle unique pour tout le logiciel est difcile, voir utopique Quid de l'interfaçage avec du code tiers ?
  • 17. Bounded context (Contexte borné) Défnir les limites précises, quels concepts sont inclus, quels besoins. Le contexte borné doit protéger son modèle du reste du code, l'isolant afn de pouvoir le faire évoluer sans nécessairement impacter le reste du monde, sauf pour des contextes bien identifés. Une équipe peut travailler sur plusieurs contextes, un contexte ne peut être manipulé que par une équipe.
  • 18. Anti corruption layer (Couche anti corruption)
  • 19. Protéger le contexte de l’extérieur Refactoring toujours possible !
  • 20. Shared kernel (Noyau partagé) Customer/supplier (Client-fournisseur) Anti corruption layer (Couche anti corruption) Conformist (Conformiste) Separate ways (Chemins séparés) Collaboration + -
  • 21. Published langage (Langage publié) Open host service (Service hôte ouvert) Anti corruption layer (Couche anti corruption) Ouverture + -
  • 22. Context map (Carte de contexte) Identife les diférents contextes bornés et leurs relations. Les noms des contextes font partie du langage omniprésent, facilitant grandement les discussions. Plusieurs types d'interactions entre contextes possibles, existence de pattern
  • 23. Distiller pour aller à l'essentiel En introduisant des sous domaines génériques pour garder le domaine essentiel au coeur. Sortir des mécanismes cohérents en soi du domaine pour les mettre dans des librairies.
  • 24. Core domain with a vision statement (Domaine central avec une vision) Il convient d’identifer le ou les domaines centraux de l’entreprise. Il s’agit généralement de ceux les plus proftables. Eric Evants préconise de leur associer une « vision claire », c’est à dire une phrase résumant leur nature et leur objectif, afn de s’assurer de ne pas en diverger par accident. Il faut également attribuer à ces domaines le plus de ressources notamment : - privilégier les domaines centraux dans les arbitrages, - y afecter les meilleurs développeurs.
  • 25. Big Ball Of Mud (grosse balle de boue)
  • 26. Mais… DDD non possible au milieu d'une Big Ball Of Mud
  • 27. Cas des Frenchies (et autres non anglophones) Comment faire quand on code dans un langage informatique en anglais et que les utilisateurs parlent français, voir également allemand ? Choisir le langage de référence, celui utilisé par les experts du domaine
  • 28. Avoir des domaines pérennes Les diférentes couches Domaine représentent le coeur de métier d’une entreprise. Leur durée de vie est souvent bien plus grande que celle des technologies utilisées. Il se peut même qu’il faille un jour porter ces règles métier sur une autre plateforme, par exemple dans une application mobile supportant un mode déconnecté. Aussi, il est important que l’adhérence des couches domaines au langage et aux outils utilisées soit contenue, afn de pouvoir aisément basculer sur de nouvelles technologies.
  • 30. Mais... tout le métier est dans un même processus Tout le métier peut appeler tout le métier  ● Tout peut dépendre de tout ● Complexité résultante importante ● Une erreur, même émanant d'une tâche sans importance, peut planter toute l'application (Out Of Memory en Java par exemple).
  • 32. The database is a subset of the logs (La base de données contient un sous ensemble des traces) Une base de données peut être utilisée de façon à mettre à jour les données. Autrement dit, si un utilisateur change de nom, on met à jour la ligne correspondante. On parle alors d'« update in place ». Ce faisant, toutefois, on perd l'ancien nom. Et peut être a t on plus d'informations dans les fchiers de logs : valeur du nouveau nom, de l'ancien, date de mise à jour... Au fnal, alors qu'on a une base de données avec plein de fonctionnalités, une bonne partie des infos se trouvent dans des fchiers textes plus durs à exploiter et souvent non conservés...
  • 33. Quid du monde réel ? Pas de mise à jour, seulement des événements. Date et données d'un événement ne changent pas. Seuls de nouveaux événements s'ajoutent.
  • 34. Evénement : date et données Idées : ● stocker les événements ● construire l'état courant à partir des événements
  • 36. Exemples d'événements UserAuthenticated(userId, date) ItemAdded(itemId, number, cartId, date) ItemRemoved(itemId, cartId, date) Verbe des événements toujours au passé : il s'agit de faits.
  • 37. Etat courant dans des vues Une vue : événements agrégés Souscrire aux événements désirés et créer des vues.
  • 38. Satisfaire exactement le besoin ! ● Duplication des données dans diférentes vues ● Données au format consommé
  • 39. Snapshots (Instantanés) Besoin de reconstruire une vue ? Faire des instantanés (snapshots) : sauvegarde de l'état de la vue à un événement donné 
  • 40. Event driven architecture (Architecture orientée événements)
  • 41. L'espace disque n'est plus une limite
  • 42. Asynchrone donc distribuable Publication/souscription : asynchrone ● Code construit avec possibilité de distribution => montée en charge
  • 43. Découplage fort ● L'émetteur de l'événement ignore tout des souscripteurs, l'événement est le seul contrat à honorer => piles techniques diférentes possibles, ouverture sur le reste du monde
  • 44. Events Log Conservation des événements suite à leur publication ● historique du système ● capacité à rejouer tout ou partie ● consommation décalée possible
  • 45. En résumé : Événements, distribution (conservation) et vues ● Changements communiqués via publication d'événements ● Événements conservés ● Événements agrégés dans des vues
  • 46. Retour au Domain Driven Design Événements pour échanger entre contextes bornés Vues pour mieux servir les lectures du domaine Code des contextes vraiment indépendant les uns des autres, voir même les piles techniques Historique
  • 47. Domain Events On en reparle dans la suite : Eric Evans s'inspire des mêmes éléments pour recommander les Domain Events
  • 48. Event Sourcing basé sur les faits, comment gérer les choses à faire ?
  • 49. CQRS Command And Query Responsibility Segregation (Ségrégation des Responsabilités de Commande et de Requête)
  • 50. Base de données  = goulet d'étranglement Constat : la base de données est un goulet d'étranglement des performances et de la modélisation
  • 51. Une base de données peut consommer 80% du CPU pour la gestion des transactions.
  • 52. Séparer lecture et écriture Écriture (Write side – Command) : une base de données Lecture (Read side - Request) : réplication de la base d'écriture vers une ou plusieurs bases de données On évoque généralement un facteur 100 en termes de gain de charge.
  • 53. Pourquoi garder un même modèle ? Par exemple si présence d’une notion d’utilisateur. Lors de l’ajout d’un utilisateur, il faut : - s’assurer de l’unicité du login - s’assurer de la présence de certains champs Seule l’unicité du login nécessite un état en base, le reste ne nécessite pas des données persistentes pour pouvoir être contrôlé. A l’inverse un afchage d’utilisateurs requiert souvent des jointures mais pas le login… => les besoins en lecture et écriture sont très diférents : un même modèle implique des compromis
  • 54. Write & Read Model (Modèles d'écriture et de lecture) Le Write model sera : ● Centré sur les invariants lors de l'écriture ● Granularité fne ● Charge limitée ● Besoin d'un support des transactions => bases relationnelles bonnes candidates Le Read model : ● Pas besoin de transactions ● Possibilité d’aggrégations ● Charge bien plus importante => nombreuses solutions possibles (NoSQL...)
  • 55. Retour à l'Event Sourcing Les écritures partagent beaucoup avec les événements. Similitudes ● Ecriture à date donnée ● Contiennent des données exprimant une demande Diférences ● Peuvent échouer ● S'ils réussissent, déclenchent des événements
  • 56. Commande Date, données, consommation unique Peut échouer Introduction de la notion de commande : ● Une date ● Une demande exprimée par les données ● Peut réussir ou non ● Consommation unique : un seul service doit décider de son succès ou non.
  • 57. Granularité fne des changements Changements via des commandes, non des entités : on peut aisément ne changer qu'une valeur, pas besoin de tout transporter.
  • 58. Ébauche d'une réponse au problème initial ● Capture du métier via le langage omniprésent ● Intégrité assurée via les contextes bornés ● Les contextes valident les commandes et émettent les événements ● Les vues agrègent les événements et permettent la lecture
  • 60. De quoi parle-t-on ? Données anciennes, pas fausses Performances meilleures que du synchrone
  • 61. Améliorations aisées Vitesse de rafraîchissement Surveillance & ajout de nœuds
  • 62. Consistance souvent illusoire Écrans non rafraîchis Transactions consécutives Cache divers Systèmes non entièrement transactionnels Niveau d'isolation des transactions baissé pour raisons de performances
  • 63. Au niveau de l'interface utilisateur Bloquer en attendant les résultats Indiquer l'en cours Combiner les deux...
  • 64. Initialement… un monolithe ! Tout dans un processus  ● Appels synchrones ● Quid de plusieurs nœuds (performance, redondance) ? Une couche métier ● Tout le code métier peut appeler tout le code métier ● Pas de séparation physique du code métier. ● Chaque entité ou concept est susceptible d'être utilisé dans n'importe quel autre bout de code, même pour des besoins divergeant. Une base de donnés ● Compromis entre les diférents besoin métier ● Goulet d'étranglement Framework  ● Quid si évolue dans un sens non désiré ? ● Quid s'il n'est plus maintenu ?
  • 65. Monolithe  = coûts exponentiels avec le temps Montées en charge difcile ● Du nombre d'utilisateur ● Du nombre de fonctionnalités ● Du nombre de développeurs Utilisation de systèmes tiers non prévue
  • 66. Système distribué Monolithe Application desktop/mobile Site promotionnel temporaire Web Scale, SaaS Application web ? Haute disponibilité, montée en charge, pérennité, ouverture technologique Facilité de mise en œuvre Court/moyen terme
  • 67. Microservices ? Défnition exacte d’un microservices compliquée mais : - synchrone ou asynchrone - portée d’un microservice très limitée -- fait juste une chose (que le transport, que la transformation, que la …) Netfix : 1/3 du trafc internet, plus de 1000 microservices
  • 69. Un système : - une IHM - un métier - des données
  • 70. Communications asynchrones entre systèmes sinon un « Distributed Monolith »...
  • 71. Event Sourcing to the rescue!
  • 72. Enchainements d’Event Sources => Stream processing Reactive Streams - Akka Streams - Kafka Streams
  • 73. Juste des fonctions entre les stream ? => Lambda architecture
  • 74. Lambda architecture Des fonctions déclenchées au besoin => serverless !
  • 76. Pour approfondir ● Event Sourcing : Talks de Rich Hickey ● CQRS : Talks de Greg Young ● Stream Processing : The Log: What every software engineer should know about real-time data's unifying abstraction ● Documentation Kafka ● Analyses de systèmes distribués ● Fallacies of Distributed Computing Explained ● Domain-Driven Design Vite fait ● Clarifed CQRS ● Designing Data-Intensive Application Frameworks/librairies souvent trop générales Approfondir via des implémentations d'event bus (Kafka )
  • 77. Remerciements Eric Evans, Rich Hickey, Greg Young : penseurs des concepts présentés  A tous ceux avec qui j’ai pu discuter et approfondir les concepts, dont - Uwe Schäfer (@codesmell) - Olivier Schneider (@Oli3dfx) A vous, pour être venu et avoir tenu si longtemps