Le document traite du design piloté par le domaine et des méthodes agiles pour améliorer le développement logiciel en s'adaptant aux besoins changeants des clients. Il souligne l'importance de la collaboration entre développeurs et clients, ainsi que l'utilisation de techniques comme le développement piloté par les tests et le langage ubiquitaire pour réduire la complexité. Différentes approches, telles que la programmation en paires et les workshops, sont également mentionnées pour renforcer la communication et l'efficacité au sein des équipes.

1. Domain Driven Design François Wauquier Agile Tour Lille 2009 - Sfeir

2. Il est difficile de capturer le besoin présent Il est impossible de capturer le besoin futur Les méthodes agile exploitent le changement comme avantage compétitif en livrant fréquemment

3. 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

4. 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

5. Design (Conception) ‘ Big Design Up Front’ ≠ Conception Emergeante Processus incrémental?

6. Domain Driven Design Eric Evans ‘ Tackling Complexity in the Heart of Software’ ‘ Model Driven Design’ ‘ Ubiquitus Language’ ‘ Supple Design’

7. Ubiquitous Language Langage commun Monsieur le client, Est-ce que ‘A’ veut dire la même chose que ‘B’ ? ‘ Domain Specific Language’

8. Test Driven Development Test avant implémentation Toujours ‘ Intention Revealing Interfaces’ ‘ Side-Effect-Free Functions’ Contrat de méthode

9. Refactoring Améliorer la lisibilité et/ou la maintenabilité du code Toujours Rendre visible les concepts cachés

10. Test Driven Requirement Spécifications exécutables Une story est définie par son parcours utilisateur et ses tests d’ acceptance client Le test d’ acceptance est écrit par le client pendant l’itération

11. Intégration continue Tests de code (TDD) Tests fonctionnels (TDR)

12. Programmation en couches Presentation Services Domain Infrastrucure Mais programmation par story!

13. Domain Entities Value Objects Factories Repositories

14. Pair Programming Pilote CoPilote Partage de connaissances Formation Nommage de classes, méthodes Suppression erreurs de typo, syntaxe, inattention On demande au client ? On fait un workshop ?

15. Workshop Equipe et client Salle toujours dispo Intense Orienté solution UML ‘ Paper Prototyping’ Métaphore

16. Organisation d’équipes ‘ Shared Kernel’ ‘ Customers /Supplier Teams’ ‘ Conformist’ ‘ Anticorruption Layer’ ‘ Separate Ways’

17. En couches ou objet? class FooServiceImpl implements FooService { FooDao fooDao; void bar (Foo foo){ foo.bar(); fooDao.saveOrUpdate(foo); } void setFooDao(FooDao fooDao){ this.fooDao = fooDao; } }

18. Merci François Wauquier Sfeir on agile way Agile France http://francois.wauquier.fr