2. Pôle Conseil Offre de conseil et d’expertise du Groupe Sodifrance Aider nos clients à répondre aux problématiques soulevées par les enjeux des technologies de l’information autour du développement et de la maintenance de leurs Systèmes d’Information : AMOA : Optimiser le cycle logiciel entre les besoins exprimés par une MOA et sa réalisation par la MOE Industrialisation & MDA : Accélérer et pérenniser les approches et les développements Accompagnement & Formation : Assurer le transfert de compétences, à travers notre organisme de formation agréé disposant de formateurs issus du monde « opérationnel ». Architecture technique J2EE /.Net S'aligner sur les nouvelles architectures et bénéficier de leurs avantages Pilotage des projets Accompagner nos clients dans la production de leurs projets à l’aide de méthodes traditionnelles ou agiles

3. Domain Driven Design ou « Comment tacler la complexité au cœur du logiciel ? »

4. But de la présentation Présenter l’idée centrale du DDD DDD est vraiment très riche Cette présentation est vraiment très courte 4

5. Origine Eric Evans 2003 5

6. Définition : le domaine Sujet auquel un utilisateur applique un programme sphère de connaissances, d’influences et d’activités =~ Métier / Business / Fonctionnel / Marché Focalisé sur la valeur ajoutée l’avantage concurrentiel 6

7. Exemple de domaine Application de fret de marchandise longue distance Avantage concurrentiel Rapidité de livraison Optimisation du fret Suivi en direct des marchandises Traçabilité Etc. 7

8. Définition : Complexité(s) d’un système logiciel Complexité inhérente relié au problème qu’il essaye de résoudre Complexité réelle relié à la taille et à la structure du système réellement construit => différence une mesure de l’incapacité à faire correspondre la solution au problème 8 - Kevlin Henney, “For the sake of simplicity” (1999)

9. DDD : Quel objectif ? Minimiser cette différence Tacler la complexité réelle Clarifier la complexité inhérente Focaliser Le logiciel sur l’avantage concurrentiel L’entreprise sur sa stratégie 9

10. Quels moyens ? Aspects techniques Techniques de modélisation Stratégies d’entreprise Principes et bonnes pratiques 10 http://www.flickr.com/photos/phploveme/2746295460

11. Quels acteurs ? Toute partie prenante L’équipe créatrice du logiciel Les experts du domaines Les utilisateurs La direction Stratégie 11

13. Modéliser le domaine vers une compréhension accrue 13

14. Définition : le modèle Représentation / vue du domaine pour un but particulier : contexte borné sous-jacente Pas « un » document UML Mais exprimé dans Le code Les discussions et le vocabulaire Des diagrammes « type-UML » 14

15. Le modèle est vivant Apprentissage permanent Brainstorming Expérimentation Récupération de connaissances Livres Utilisateurs Modèles déjà publiés … Collaboration avec les experts du domaine 15

16. 16 Expression purifiée de l’éléctromagnétisme James Clerk Maxwell, A Treatise on Electricity andMagnetism, 1873

17. Un langage omniprésent(ubiquitous language) Bruegel 17

18. 18 Des analystes de terrain,des hommes de terrains analystes

19. Distiller le domaine Extraire l’essence du domaine 19

20. Cœur du domaine Y mettre Ce qui a le plus de valeur Avantage concurrentiel Le faire Petit L’attribuer aux développeurs Talentueux Tendances contraires ! Pérennes internes 20

21. Sous-domaines génériques Ensembles de concepts Cohérents N’étant pas la motivation propre du projet En support des autres domaines Ne pas mettre les développeurs principaux Considérer les solutions Sur étagère Externalisés Exemple Gestion de fuseaux horaires Pas forcément réutilisable non prioritaire 21

22. Cartographier le Système, ses interactions et ses contextes Maintenir l’intégrité du modèle 22

23. Contexte borné (boundedcontext) http://www.infoq.com/articles/ddd-contextmapping Alberto Brandolini 23

24. Cartographie des contextes Interactions entre composant des systèmes Les modules de l’application entre eux Les applications entre elles http://www.infoq.com/articles/ddd-contextmapping Alberto Brandolini 24

25. Noyau partagé Eric Evans, DOMAIN-DRIVEN DESIGN, Addison-Wesley,  Eric Evans, 2004. Creative Commons Deed: Attribution 2.0 25

26. Client / fournisseur http://www.flickr.com/photos/chilangoco/ 26

27. Conformiste http://www.flickr.com/photos/mckaysavage/ 27

28. http://www.flickr.com/photos/hansol/ 28

29. Hôte ouvert http://www.flickr.com/photos/57768426@N00/ 29

30. Couche anti-corruption Expose des services traités par un autre sous-système (legacy) Dans le langage ubiquitaire Met en valeur le strict nécessaire de ce sous système Pattern façade Relie les deux Patterns adaptateurs 30

31. Exemple de carte http://www.infoq.com/articles/ddd-contextmapping Alberto Brandolini 31

32. Conclusion 32

33. L’essentiel Collaboration créative entre experts du domaine et experts du logiciel Exploration et expérimentation Modèles émergents formant et reformant le langage ubiquitaire Frontières des contextes explicites Se concentrer sur le cœur domaine 33

34. http://www.flickr.com/photos/phploveme/2746295460

35. 35 ? Questions http://blog.anteo-consulting.com/ gcollic@sodifrance.fr