Domain Driven Design                                  & Agilité ...  C omprendre,  C ommuniquer,  C oder François Wauquier...
Il est difficile de capturer le besoin présent
Il est impossible de capturer le besoin futur
Les méthodes Agiles exploitent le changement comme avantage compétitif en livrant fréquemment
  Il etait une fois un projet J'ai un besoin Je réalise un logiciel
<ul><ul><li>&quot;Il n'y a pas de classe  SiègeAvion &quot; </li></ul></ul><ul><ul><li>&quot;Je pense que ça se passe comm...
<ul><ul><li>Je ne comprends rien à vos noms de classes </li></ul></ul><ul><ul><li>Je dois terminer ma spec fonctionnelle p...
Retour sur le Manifeste Agile
  Retour sur le manifeste Agile <ul><ul><li>Les individus et les interactions plutôt que les processus et les outils </li>...
  Accepter le changement <ul><ul><li>Accueillir l'évolution des besoins, même tard dans le développement </li></ul></ul><u...
  Design = Conception <ul><ul><li>Modéliser </li></ul></ul><ul><ul><li>Représenter </li></ul></ul><ul><ul><li>Faire des ch...
  Design & design <ul><ul><li>‘ Big Design Up Front’ ≠ Conception Emergeante </li></ul></ul><ul><ul><li>Reloadus ≠ Oryzus ...
Domain Driven Design
  Ubiquitous Language <ul><ul><li>Langage commun </li></ul></ul><ul><ul><li>Monsieur le client, est-ce que ‘A’ veut dire l...
  Core Domain <ul><ul><li>(Re)définir le coeur d'une application </li></ul></ul><ul><ul><li>Not Invented Here syndrom </li...
  Programmation en couches <ul><ul><li>Presentation </li></ul></ul><ul><ul><li>Services </li></ul></ul><ul><ul><li>Domain ...
  Domain Building Blocks <ul><ul><li>Entities </li></ul></ul><ul><ul><li>Value Objects </li></ul></ul><ul><ul><li>Factorie...
<ul><li>Crédit photo : AxelRD licence Commons Creatives 2.0 http://www.flickr.com/photos/axelrd/ </li></ul>DDD et l'écosys...
Votre projet et les autres équipes <ul><ul><li>‘ Shared Kernel’ </li></ul></ul><ul><ul><li>‘ Customers /Supplier Teams’ </...
<ul><li>Contrôle en amont </li></ul>Amont / Aval
<ul><li>Flux incontrolable </li></ul>Amont / Aval
<ul><li>Communication entre 2 &quot;Bounded context&quot; </li></ul>Amont / Aval
  Pratiques Agiles et DDD ?
  Test Driven Development <ul><ul><li>‘ Intention Revealing Interfaces’ </li></ul></ul><ul><ul><li>‘ Side-Effect-Free Func...
  Refactoring <ul><ul><li>Rendre visible les concepts cachés </li></ul></ul><ul><ul><li>Tailler le code, prendre en compte...
  Test Driven Requirement <ul><ul><li>Une story est définie par ses tests d'acceptance,écrit par  le client ET un develope...
  Pair Programming <ul><ul><li>Pilote + CoPilote </li></ul></ul><ul><ul><li>Partage de connaissances </li></ul></ul><ul><u...
  Workshop <ul><ul><li>Equipe et client/PO/Expert </li></ul></ul><ul><ul><li>Intense </li></ul></ul><ul><ul><li>Orienté so...
  Vers la source du besoin
  Un peu de code ? Crédit photo : ignWallah http://www.flickr.com/photos/designwallah/ Licences Commons Creatives 2.0
sans DDD class ShipServiceImpl implements ShipService{      ShipDao shipDao;      void  navigate (Ship ship){          //n...
  avec DDD class ShipService{           void  navigate (Ship ship){            ship.navigate();           }   } @Entity cl...
  Conclusion <ul><ul><li>Developpeurs, comprenez votre client </li></ul></ul><ul><ul><li>Client, comprenez votre équipe </...
  Domain Driven Design  Eric Evans ™ <ul><ul><li>‘ Tackling Complexity in the Heart of Software’ </li></ul></ul>
  Merci <ul><ul><li>François Wauquier http://blog.onagileway.fr @wokier </li></ul></ul><ul><ul><li>Nicolas Martignole  htt...
Prochain SlideShare
Chargement dans…5
×

Domain Driven Design - Agile France 2010

875 vues

Publié le

Présentation faite avec Nicolas Martignole dit "le touilleur"

Publié dans : Design, Technologie
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
875
Sur SlideShare
0
Issues des intégrations
0
Intégrations
25
Actions
Partages
0
Téléchargements
13
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Domain Driven Design - Agile France 2010

  1. 1. Domain Driven Design                                  & Agilité ... C omprendre, C ommuniquer, C oder François Wauquier Nicolas Martignole
  2. 2. Il est difficile de capturer le besoin présent
  3. 3. Il est impossible de capturer le besoin futur
  4. 4. Les méthodes Agiles exploitent le changement comme avantage compétitif en livrant fréquemment
  5. 5.   Il etait une fois un projet J'ai un besoin Je réalise un logiciel
  6. 6. <ul><ul><li>&quot;Il n'y a pas de classe SiègeAvion &quot; </li></ul></ul><ul><ul><li>&quot;Je pense que ça se passe comme ça...&quot; </li></ul></ul><ul><ul><li>&quot;Mince l'API a changé&quot; </li></ul></ul><ul><ul><li>&quot;J'ai écrit un super framework de log&quot; </li></ul></ul>Vis ma vie de développeur
  7. 7. <ul><ul><li>Je ne comprends rien à vos noms de classes </li></ul></ul><ul><ul><li>Je dois terminer ma spec fonctionnelle pour parler au développeur </li></ul></ul><ul><ul><li>Ce n'est pas ce que j'avais demandé </li></ul></ul>Vis ma vie de client
  8. 8. Retour sur le Manifeste Agile
  9. 9.   Retour sur le manifeste Agile <ul><ul><li>Les individus et les interactions plutôt que les processus et les outils </li></ul></ul><ul><ul><li>Un logiciel qui fonctionne plutôt que une documentation détaillée </li></ul></ul><ul><ul><li>La collaboration avec le client plutôt que la négociation de contrats </li></ul></ul><ul><ul><li>Accepter le changement plutôt que suivre le plan </li></ul></ul>
  10. 10.   Accepter le changement <ul><ul><li>Accueillir l'évolution des besoins, même tard dans le développement </li></ul></ul><ul><ul><li>Les gens de l'art et les développeurs doivent travailler ensemble quotidiennement tout au long du projet </li></ul></ul>
  11. 11.   Design = Conception <ul><ul><li>Modéliser </li></ul></ul><ul><ul><li>Représenter </li></ul></ul><ul><ul><li>Faire des choix </li></ul></ul><ul><ul><li>Créer un logiciel </li></ul></ul>
  12. 12.   Design & design <ul><ul><li>‘ Big Design Up Front’ ≠ Conception Emergeante </li></ul></ul><ul><ul><li>Reloadus ≠ Oryzus </li></ul></ul><ul><ul><li>Processus incrémental? </li></ul></ul>
  13. 13. Domain Driven Design
  14. 14.   Ubiquitous Language <ul><ul><li>Langage commun </li></ul></ul><ul><ul><li>Monsieur le client, est-ce que ‘A’ veut dire la même chose que ‘B’ ? </li></ul></ul><ul><ul><li>‘ Domain Specific Language’ </li></ul></ul><ul><ul><li>le franglais ? </li></ul></ul>
  15. 15.   Core Domain <ul><ul><li>(Re)définir le coeur d'une application </li></ul></ul><ul><ul><li>Not Invented Here syndrom </li></ul></ul><ul><li>Fonctionnalités </li></ul><ul><ul><li>Core </li></ul></ul><ul><ul><li>Supporting </li></ul></ul><ul><ul><li>Generic </li></ul></ul>
  16. 16.   Programmation en couches <ul><ul><li>Presentation </li></ul></ul><ul><ul><li>Services </li></ul></ul><ul><ul><li>Domain </li></ul></ul><ul><ul><li>Infrastrucure </li></ul></ul><ul><ul><li>Mais programmation Objet! </li></ul></ul><ul><ul><li>Mais programmation par Story! </li></ul></ul>Story
  17. 17.   Domain Building Blocks <ul><ul><li>Entities </li></ul></ul><ul><ul><li>Value Objects </li></ul></ul><ul><ul><li>Factories </li></ul></ul><ul><ul><li>Repositories </li></ul></ul>
  18. 18. <ul><li>Crédit photo : AxelRD licence Commons Creatives 2.0 http://www.flickr.com/photos/axelrd/ </li></ul>DDD et l'écosystème de votre projet Les Strategics Patterns
  19. 19. Votre projet et les autres équipes <ul><ul><li>‘ Shared Kernel’ </li></ul></ul><ul><ul><li>‘ Customers /Supplier Teams’ </li></ul></ul><ul><ul><li>‘ Conformist’ </li></ul></ul><ul><ul><li>‘ Anticorruption Layer’ </li></ul></ul><ul><ul><li>‘ Separate Ways’ </li></ul></ul>Confiance
  20. 20. <ul><li>Contrôle en amont </li></ul>Amont / Aval
  21. 21. <ul><li>Flux incontrolable </li></ul>Amont / Aval
  22. 22. <ul><li>Communication entre 2 &quot;Bounded context&quot; </li></ul>Amont / Aval
  23. 23.   Pratiques Agiles et DDD ?
  24. 24.   Test Driven Development <ul><ul><li>‘ Intention Revealing Interfaces’ </li></ul></ul><ul><ul><li>‘ Side-Effect-Free Functions’ </li></ul></ul><ul><ul><li>Contrat de méthode </li></ul></ul>
  25. 25.   Refactoring <ul><ul><li>Rendre visible les concepts cachés </li></ul></ul><ul><ul><li>Tailler le code, prendre en compte les évolutions </li></ul></ul><ul><ul><li>Pattern Spécification  </li></ul></ul>
  26. 26.   Test Driven Requirement <ul><ul><li>Une story est définie par ses tests d'acceptance,écrit par le client ET un developeur avant/pendant l’itération </li></ul></ul><ul><ul><li>Échanger </li></ul></ul><ul><ul><li>Créer un langage commun </li></ul></ul>
  27. 27.   Pair Programming <ul><ul><li>Pilote + CoPilote </li></ul></ul><ul><ul><li>Partage de connaissances </li></ul></ul><ul><ul><li>Nommage de classes, méthodes </li></ul></ul><ul><ul><li>On demande au client ? </li></ul></ul><ul><ul><li>On fait un workshop ? </li></ul></ul>
  28. 28.   Workshop <ul><ul><li>Equipe et client/PO/Expert </li></ul></ul><ul><ul><li>Intense </li></ul></ul><ul><ul><li>Orienté solution </li></ul></ul><ul><ul><li>UML </li></ul></ul><ul><ul><li>‘ Paper Prototyping’ </li></ul></ul><ul><ul><li>Métaphore </li></ul></ul>
  29. 29.   Vers la source du besoin
  30. 30.   Un peu de code ? Crédit photo : ignWallah http://www.flickr.com/photos/designwallah/ Licences Commons Creatives 2.0
  31. 31. sans DDD class ShipServiceImpl implements ShipService{      ShipDao shipDao;      void  navigate (Ship ship){          //navigation rules...          shipDao.saveOrUpdate(ship);      }      void setShipDao(ShipDao shipDao){          this.shipDao = shipDao;      } } class Ship{     }
  32. 32.   avec DDD class ShipService{           void  navigate (Ship ship){            ship.navigate();           }   } @Entity class Ship {      void navigate(){          //navigation rules...          save();      } }
  33. 33.   Conclusion <ul><ul><li>Developpeurs, comprenez votre client </li></ul></ul><ul><ul><li>Client, comprenez votre équipe </li></ul></ul><ul><ul><li>Parlez le même langage! </li></ul></ul>
  34. 34.   Domain Driven Design Eric Evans ™ <ul><ul><li>‘ Tackling Complexity in the Heart of Software’ </li></ul></ul>
  35. 35.   Merci <ul><ul><li>François Wauquier http://blog.onagileway.fr @wokier </li></ul></ul><ul><ul><li>Nicolas Martignole  http://touilleur-express.fr @nmartignole </li></ul></ul>

×