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