Anteo Mda Aosd

598 vues

Publié le

Publié dans : Technologie, Business
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
598
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
9
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Anteo Mda Aosd

  1. 1.
  2. 2. Pôle Conseil<br />Offre de conseil et d’expertise du Groupe Sodifrance<br />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 :<br />AMOA :<br />Optimiser le cycle logiciel entre les besoins exprimés par une MOA et sa réalisation par la MOE<br /> Industrialisation & MDA :<br />Accélérer et pérenniser les approches et les développements<br />Accompagnement & Formation :<br />Assurer le transfert de compétences, à travers notre organisme de formation agréé disposant de formateurs issus du monde « opérationnel ».<br /> Architecture technique J2EE /.Net<br />S'aligner sur les nouvelles architectures et bénéficier de leurs avantages<br /> Pilotage des projets <br />Accompagner nos clients dans la production de leurs projets à l’aide de méthodes traditionnelles ou agiles<br />
  3. 3. Domain Driven Design<br />ou « Comment tacler la complexité au cœur du logiciel ? »<br />
  4. 4. But de la présentation<br />Présenter l’idée centrale du DDD<br />DDD est vraiment très riche<br />Cette présentation est vraiment très courte<br />4<br />
  5. 5. Origine<br />Eric Evans<br />2003<br />5<br />
  6. 6. Définition : le domaine<br />Sujet auquel un utilisateur applique un programme<br />sphère de connaissances, d’influences et d’activités<br />=~ Métier / Business / Fonctionnel / Marché <br />Focalisé sur<br />la valeur ajoutée<br />l’avantage concurrentiel<br />6<br />
  7. 7. Exemple de domaine<br />Application de fret de marchandise longue distance<br />Avantage concurrentiel<br />Rapidité de livraison<br />Optimisation du fret<br />Suivi en direct des marchandises<br />Traçabilité<br />Etc.<br />7<br />
  8. 8. Définition : Complexité(s) d’un système logiciel <br />Complexité inhérente<br />relié au problème qu’il essaye de résoudre<br />Complexité réelle <br />relié à la taille et à la structure du système réellement construit<br />=> différence<br />une mesure de l’incapacité à faire correspondre la solution au problème<br />8<br />- Kevlin Henney, “For the sake of simplicity” (1999)<br />
  9. 9. DDD : Quel objectif ?<br />Minimiser cette différence<br />Tacler la complexité réelle<br />Clarifier la complexité inhérente<br />Focaliser<br />Le logiciel sur l’avantage concurrentiel<br />L’entreprise sur sa stratégie<br />9<br />
  10. 10. Quels moyens ?<br />Aspects techniques<br />Techniques de modélisation<br />Stratégies d’entreprise<br />Principes et bonnes pratiques<br />10<br />http://www.flickr.com/photos/phploveme/2746295460    <br />
  11. 11. Quels acteurs ?<br />Toute partie prenante<br />L’équipe créatrice du logiciel<br />Les experts du domaines<br />Les utilisateurs<br />La direction<br />Stratégie<br />11<br />
  12. 12. Pré-requis<br />Processus itératif<br />Accès aux experts du domaine<br /><ul><li>Agilité</li></ul>12<br />
  13. 13. Modéliser le domaine<br />vers une compréhension accrue<br />13<br />
  14. 14. Définition : le modèle<br />Représentation / vue<br />du domaine<br />pour un but particulier : contexte borné<br />sous-jacente<br />Pas<br />« un » document UML<br />Mais exprimé dans<br />Le code<br />Les discussions et le vocabulaire<br />Des diagrammes « type-UML »<br />14<br />
  15. 15. Le modèle est vivant<br />Apprentissage permanent<br />Brainstorming<br />Expérimentation<br />Récupération de connaissances<br />Livres<br />Utilisateurs<br />Modèles déjà publiés<br />…<br />Collaboration avec les experts du domaine<br />15<br />
  16. 16. 16<br />Expression purifiée de l’éléctromagnétisme<br />James Clerk Maxwell, A Treatise on Electricity andMagnetism, 1873<br />
  17. 17. Un langage omniprésent(ubiquitous language)<br />Bruegel<br />17<br />
  18. 18. 18<br />Des analystes de terrain,des hommes de terrains analystes<br />
  19. 19. Distiller le domaine<br />Extraire l’essence du domaine<br />19<br />
  20. 20. Cœur du domaine<br />Y mettre<br />Ce qui a le plus de valeur<br />Avantage concurrentiel<br />Le faire<br />Petit<br />L’attribuer<br />aux développeurs <br />Talentueux<br />Tendances contraires !<br />Pérennes <br />internes<br />20<br />
  21. 21. Sous-domaines génériques<br />Ensembles de concepts<br />Cohérents<br />N’étant pas la motivation propre du projet<br />En support des autres domaines<br />Ne pas mettre les développeurs principaux<br />Considérer les solutions<br />Sur étagère<br />Externalisés<br />Exemple<br />Gestion de fuseaux horaires<br />Pas forcément réutilisable<br />non prioritaire<br />21<br />
  22. 22. Cartographier le Système, ses interactions et ses contextes<br />Maintenir l’intégrité du modèle<br />22<br />
  23. 23. Contexte borné (boundedcontext)<br />http://www.infoq.com/articles/ddd-contextmapping<br />Alberto Brandolini<br />23<br />
  24. 24. Cartographie des contextes<br />Interactions entre composant des systèmes<br />Les modules de l’application entre eux<br />Les applications entre elles <br />http://www.infoq.com/articles/ddd-contextmapping<br />Alberto Brandolini<br />24<br />
  25. 25. Noyau partagé<br />Eric Evans, DOMAIN-DRIVEN DESIGN, Addison-Wesley,  Eric Evans, 2004.<br />Creative Commons Deed: Attribution 2.0<br />25<br />
  26. 26. Client / fournisseur<br />http://www.flickr.com/photos/chilangoco/    <br />26<br />
  27. 27. Conformiste<br />http://www.flickr.com/photos/mckaysavage/    <br />27<br />
  28. 28. http://www.flickr.com/photos/hansol/    <br />28<br />
  29. 29. Hôte ouvert<br />http://www.flickr.com/photos/57768426@N00/    <br />29<br />
  30. 30. Couche anti-corruption<br />Expose des services traités par un autre sous-système (legacy)<br />Dans le langage ubiquitaire<br />Met en valeur le strict nécessaire de ce sous système<br />Pattern façade <br />Relie les deux<br />Patterns adaptateurs<br />30<br />
  31. 31. Exemple de carte<br />http://www.infoq.com/articles/ddd-contextmapping<br />Alberto Brandolini<br />31<br />
  32. 32. Conclusion<br />32<br />
  33. 33. L’essentiel<br />Collaboration créative entre experts du domaine et experts du logiciel<br />Exploration et expérimentation<br />Modèles émergents formant et reformant le langage ubiquitaire<br />Frontières des contextes explicites<br />Se concentrer sur le cœur domaine<br />33<br />
  34. 34. http://www.flickr.com/photos/phploveme/2746295460    <br />
  35. 35. 35<br />?<br />Questions<br />http://blog.anteo-consulting.com/<br />gcollic@sodifrance.fr<br />

×