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