Le document traite des services de conseil offerts par Sodifrance pour aider les clients à optimiser leurs systèmes d'information, en se concentrant sur des approches comme le Domain Driven Design (DDD) pour gérer la complexité logicielle. Il souligne l'importance de la collaboration entre les experts du domaine et les développeurs, ainsi que l'usage de techniques de modélisation pour améliorer la compréhension des besoins métier. Enfin, il présente les principes de conception et les interactions nécessaires pour maintenir l'intégrité des systèmes en fonction des contextes définis.

2. Pôle ConseilOffre de conseil et d’expertise du Groupe SodifranceAider 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éveloppementsAccompagnement & Formation :Assurer le transfert de compétences, à travers notre organisme de formation agréé disposant de formateurs issus du monde « opérationnel ». Architecture technique J2EE /.NetS'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 Designou « Comment tacler la complexité au cœur du logiciel ? »

4. But de la présentationPrésenter l’idée centrale du DDDDDD est vraiment très richeCette présentation est vraiment très courte4

5. OrigineEric Evans20035

6. Définition : le domaineSujet auquel un utilisateur applique un programmesphère de connaissances, d’influences et d’activités=~ Métier / Business / Fonctionnel / Marché Focalisé surla valeur ajoutéel’avantage concurrentiel6

7. Exemple de domaineApplication de fret de marchandise longue distanceAvantage concurrentielRapidité de livraisonOptimisation du fretSuivi en direct des marchandisesTraçabilitéEtc.7

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

9. DDD : Quel objectif ?Minimiser cette différenceTacler la complexité réelleClarifier la complexité inhérenteFocaliserLe logiciel sur l’avantage concurrentielL’entreprise sur sa stratégie9

10. Quels moyens ?Aspects techniquesTechniques de modélisationStratégies d’entreprisePrincipes et bonnes pratiques10http://www.flickr.com/photos/phploveme/2746295460

11. Quels acteurs ?Toute partie prenanteL’équipe créatrice du logicielLes experts du domainesLes utilisateursLa directionStratégie11

12. Pré-requisProcessus itératifAccès aux experts du domaineAgilité12

13. Modéliser le domainevers une compréhension accrue13

14. Définition : le modèleReprésentation / vuedu domainepour un but particulier : contexte bornésous-jacentePas« un » document UMLMais exprimé dansLe codeLes discussions et le vocabulaireDes diagrammes « type-UML »14

15. Le modèle est vivantApprentissage permanentBrainstormingExpérimentationRécupération de connaissancesLivresUtilisateursModèles déjà publiés…Collaboration avec les experts du domaine15

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

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

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

19. Distiller le domaineExtraire l’essence du domaine19

20. Cœur du domaineY mettreCe qui a le plus de valeurAvantage concurrentielLe fairePetitL’attribueraux développeurs TalentueuxTendances contraires !Pérennes internes20

21. Sous-domaines génériquesEnsembles de conceptsCohérentsN’étant pas la motivation propre du projetEn support des autres domainesNe pas mettre les développeurs principauxConsidérer les solutionsSur étagèreExternalisésExempleGestion de fuseaux horairesPas forcément réutilisablenon prioritaire21

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

23. Contexte borné (boundedcontext)http://www.infoq.com/articles/ddd-contextmappingAlberto Brandolini23

24. Cartographie des contextesInteractions entre composant des systèmesLes modules de l’application entre euxLes applications entre elles http://www.infoq.com/articles/ddd-contextmappingAlberto Brandolini24

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

26. Client / fournisseurhttp://www.flickr.com/photos/chilangoco/ 26

27. Conformistehttp://www.flickr.com/photos/mckaysavage/ 27

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

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

30. Couche anti-corruptionExpose des services traités par un autre sous-système (legacy)Dans le langage ubiquitaireMet en valeur le strict nécessaire de ce sous systèmePattern façade Relie les deuxPatterns adaptateurs30

31. Exemple de cartehttp://www.infoq.com/articles/ddd-contextmappingAlberto Brandolini31

32. Conclusion32

33. L’essentielCollaboration créative entre experts du domaine et experts du logicielExploration et expérimentationModèles émergents formant et reformant le langage ubiquitaireFrontières des contextes explicitesSe concentrer sur le cœur domaine33

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

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