palais descongrèsParis7, 8 et 9février 2012
« Les logiciels c’est comme lescathédrales, d’abord on les construit, etensuite on prie »                        Développe...
Patterns et Antipatternsd’architecture pour lesapplications d’entreprise7 Février 2012Riana RambonimananaDéveloppeur .NETC...
Agenda  Rappels  Patterns et Antipatterns      Organiser les logiques métier      Accéder aux données      Gérer la distri...
RappelsRedessinons le contexte
Rappels Application d’entreprise ( * Fowler )      Grande quantité de donnée      Système de persistance      Multi utilis...
Rappels Architecture      L’ensemble des aspects techniques qui sont     importants pour le logiciel      Les choix archit...
Rappels Patterns      Formalisation de solutions courantes à des problèmes     récurrents      Moyen efficace de partager ...
Rappels Antipatterns      Pratiques courantes mais contreproductives      Résulte souvent de patterns mal utilisés      Co...
Rappels Business logic ( logique métier )      Business rules + Workflows      Souvent séparé en deux catégories :        ...
Patterns et AntipatternsRéutilisons ce qui marche
Les couches          Presentation                                     Communication interprocessus            Service     ...
Organiser les logiques métier
Pattern : Transaction script         Presentation                                    Communication interprocessus         ...
Pattern : Transaction scriptChaque “use case” est réalisé par une méthode qui exécute toute lalogique correspondante.     ...
Pattern : Transaction scriptPoints forts :              Points faibles   Implémentation facile      Réutilisabilité &   ...
Pattern : Domain Model        Presentation                                   Communication interprocessus          Service...
Pattern : Domain ModelLes logiques sont partagées par plusieurs objets qui collaborent poursatisfaire les demandes.       ...
Pattern : Domain ModelPoints forts :                 Points faibles   Exploite le paradigme         Mise en place plus  ...
Pattern : Service Layer         Presentation                                    Communication interprocessus           Ser...
Pattern : Service Layer Constitue un point d’entrée unique pour l’extérieur et orchestre les demandes entrantes, mais délè...
Choisir ?                   Transaction scriptCoût de mise enplace etmaintenance                              Domain model...
Accéder aux données
Pattern : Data mapper         Presentation                                    Communication interprocessus           Servi...
Pattern : Data mapper   Découple entièrement le modèle objet et le modèle de donnée et   prends en charge le mapping entre...
Pattern : Repository         Presentation                                    Communication interprocessus           Servic...
Pattern : Repository Isole le Domain model de l’accès aux données rendant ainsi le Domain Model indépendant, réutilisable ...
Gérer la distribution
Pattern : Data Transfer Object         Presentation                                     Communication interprocessus      ...
Pattern : Data Transfer ObjectObjet servant uniquement à transporter des données et qui a pour butd’optimiser les échanges...
Pattern : Remote Facade        Presentation                                   Communication interprocessus          Servic...
Pattern : Remote FacadePoint d’entrée au système pour les appels distants. Son but serad’optimiser les échanges réseau en ...
Démo : Exemples d’implémentation« En théorie, il n’y a pas de différence entre la théorie et lapratique, mais en pratique,...
Résumé         Presentation                                    Communication interprocessus           Service             ...
Introduction à DDD et CQRS
Domain Driven Design
Domain Driven Design (DDD) Créé et formalisé par Eric Evans en 2004 dans son livre éponyme
Domain Driven Design (DDD) Constats :      La vraie complexité réside dans le domaine lui même     et non dans les aspects...
Domain Driven Design (DDD) Pourquoi DDD ?      Nous aider à développer des logiciels qui s’attaquent     à des domaines co...
Domain Driven Design (DDD) Mais qu’est ce que c’est ? Ni une architecture, ni une méthode, plutôt une philosophie       Pr...
Domain Driven Design (DDD) Appliquer DDD   Prérequis : Expert Métier   Définir un ”Ubiquitous Language”   Modélisation du ...
Command & Query Responsibility Segregation
CQRS Origine :    Issu de la communauté mais popularisé par Greg Young (2009) et d’autres ( Udi Dahan etc..). Pourquoi CQR...
CQRS  Mais qu’est ce que c’est ? Application au niveau architectural de Command Query Separation (CQS) Command : change l’...
CQRS             Architecture “Standard”             Presentation       DTO Lecture                         DTO Ecriture  ...
CQRS Lecture            Presentation                                                         Ecriture                     ...
CQRS                    Presentation                                              Command            Query                ...
CQRS                    Presentation                                              Command            Query                ...
Conclusion
Conclusion   Si vous n’avez pas tout retenu, pas de panique !
Conclusion   Les technologies changent, les grands concepts restent.
Références   Patterns of Enterprise Application Architecture (PoEAA)                    Martin Fowler ( 2003 )
Références DDD   Communauté :       http://domaindrivendesign.org       http://tech.groups.yahoo.com/group/domaindrivendes...
Références CQRS   Communauté :       http://www.cqrsinfo.com/       http://abdullin.com/wiki/command-query-responsibility-...
Questions ?
Architecture des applications métiers
Prochain SlideShare
Chargement dans…5
×

Architecture des applications métiers

1 678 vues

Publié le

Présente des patterns et antipatterns pour la conception d'application d'entreprise. Cette présentation contient aussi une introduction à DDD et CQRS

Publié dans : Technologie
1 commentaire
1 j’aime
Statistiques
Remarques
Aucun téléchargement
Vues
Nombre de vues
1 678
Sur SlideShare
0
Issues des intégrations
0
Intégrations
1
Actions
Partages
0
Téléchargements
46
Commentaires
1
J’aime
1
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Architecture des applications métiers

  1. 1. palais descongrèsParis7, 8 et 9février 2012
  2. 2. « Les logiciels c’est comme lescathédrales, d’abord on les construit, etensuite on prie » Développeur anonyme
  3. 3. Patterns et Antipatternsd’architecture pour lesapplications d’entreprise7 Février 2012Riana RambonimananaDéveloppeur .NETCitégestion
  4. 4. Agenda Rappels Patterns et Antipatterns Organiser les logiques métier Accéder aux données Gérer la distribution Exemples d’implémentation Introduction à DDD et CQRS Conclusion Questions / Réponses
  5. 5. RappelsRedessinons le contexte
  6. 6. Rappels Application d’entreprise ( * Fowler ) Grande quantité de donnée Système de persistance Multi utilisateurs Logique métier souvent complexe
  7. 7. Rappels Architecture L’ensemble des aspects techniques qui sont importants pour le logiciel Les choix architecturaux influent sur la réussite ou l’échec d’un projet
  8. 8. Rappels Patterns Formalisation de solutions courantes à des problèmes récurrents Moyen efficace de partager les connaissances Pratiques éprouvées et considérées comme bonnes Différentes catégories (design, analyse, architecture etc.)
  9. 9. Rappels Antipatterns Pratiques courantes mais contreproductives Résulte souvent de patterns mal utilisés Conduit à des coûts élevés de développement
  10. 10. Rappels Business logic ( logique métier ) Business rules + Workflows Souvent séparé en deux catégories : Domain logic Application logic
  11. 11. Patterns et AntipatternsRéutilisons ce qui marche
  12. 12. Les couches Presentation Communication interprocessus Service Patterns pour Data Transfer Object (DTO) l’organisation de la Remote Facade logique métier Service layer Patterns pour l’accès aux Business données Transaction script Domain model Patterns pour les problèmes de Data access distribution Repository Data mapper
  13. 13. Organiser les logiques métier
  14. 14. Pattern : Transaction script Presentation Communication interprocessus Service Data Transfer Object (DTO) Remote Facade Service layer Business Transaction script Domain model Data access Repository Data mapper
  15. 15. Pattern : Transaction scriptChaque “use case” est réalisé par une méthode qui exécute toute lalogique correspondante. GestionCommande CommanderArticle() Requête Client Domain Logic Application Logic Transaction script FaireUneReclamation() Requête Client
  16. 16. Pattern : Transaction scriptPoints forts : Points faibles Implémentation facile  Réutilisabilité & du à l’approche extensibilité limités procédurale  Ne convient pas aux Convient bien aux logiques complexes logiques simplesAntipatterns fréquents : God class Spaghetti code Copy-paste
  17. 17. Pattern : Domain Model Presentation Communication interprocessus Service Data Transfer Object (DTO) Remote Facade Service layer Business Transaction Script Domain model Data access Repository Data mapper
  18. 18. Pattern : Domain ModelLes logiques sont partagées par plusieurs objets qui collaborent poursatisfaire les demandes. Domain model Requête Command Client e Domain Logic Client Application Logic Requête Client Reclamation
  19. 19. Pattern : Domain ModelPoints forts : Points faibles Exploite le paradigme  Mise en place plus objet = extensibilité et longue réutilisabilité  Nécessite de vrais Convient bien aux compétences objets logiques complexes  Mappage complexe Testabilité améliorée avec la persistance (TDD etc.)Antipatterns fréquents : Anemic Domain model
  20. 20. Pattern : Service Layer Presentation Communication interprocessus Service Data Transfer Object (DTO) Remote Facade Service layer Business Transaction script Domain model Data access Repository Data mapper
  21. 21. Pattern : Service Layer Constitue un point d’entrée unique pour l’extérieur et orchestre les demandes entrantes, mais délègue la majorité des tâches au Domain model. Service Layer CommandeRequête Client Domain Logic Client Application Logic ReclamationRequête Client
  22. 22. Choisir ? Transaction scriptCoût de mise enplace etmaintenance Domain model Complexité de la logique métier
  23. 23. Accéder aux données
  24. 24. Pattern : Data mapper Presentation Communication interprocessus Service Data Transfer Object (DTO) Remote Facade Service layer Business Transaction script Domain model Data access Repository Data mapper
  25. 25. Pattern : Data mapper Découple entièrement le modèle objet et le modèle de donnée et prends en charge le mapping entre les deux mondes. Data mapperDomain model Client Achat Schéma Client ClientFidele Achat NouveauClient
  26. 26. Pattern : Repository Presentation Communication interprocessus Service Data Transfer Object (DTO) Remote Facade Service layer Business Transaction script Domain model Data access Repository Data mapper
  27. 27. Pattern : Repository Isole le Domain model de l’accès aux données rendant ainsi le Domain Model indépendant, réutilisable et facilement testable.Domain model Data mapper Repository DB
  28. 28. Gérer la distribution
  29. 29. Pattern : Data Transfer Object Presentation Communication interprocessus Service Data Transfer Object (DTO) Remote Facade Service layer Business Transaction script Domain model Data access Repository Data mapper
  30. 30. Pattern : Data Transfer ObjectObjet servant uniquement à transporter des données et qui a pour butd’optimiser les échanges lors de communications interprocessus. Tier 1 Tier 2 Presentation DTO Service
  31. 31. Pattern : Remote Facade Presentation Communication interprocessus Service Data Transfer Object (DTO) Remote Facade Service layer Business Transaction script Domain model Data access Repository Data mapper
  32. 32. Pattern : Remote FacadePoint d’entrée au système pour les appels distants. Son but serad’optimiser les échanges réseau en offrant une interface à fortegranularité. Tier 1 Tier 2 Service Layer Remote Facade Preentation DTO
  33. 33. Démo : Exemples d’implémentation« En théorie, il n’y a pas de différence entre la théorie et lapratique, mais en pratique, il y en a » ( Loi de Murphy)
  34. 34. Résumé Presentation Communication interprocessus Service Patterns pour Data Transfer Object (DTO) l’organisation de la Remote Facade logique métier Service layer Patterns pour l’accès aux Business données Transaction script Domain model Patterns pour les problèmes de Data access distribution Repository Data mapper
  35. 35. Introduction à DDD et CQRS
  36. 36. Domain Driven Design
  37. 37. Domain Driven Design (DDD) Créé et formalisé par Eric Evans en 2004 dans son livre éponyme
  38. 38. Domain Driven Design (DDD) Constats : La vraie complexité réside dans le domaine lui même et non dans les aspects techniques. Le design conditionne jusqu’ou un projet peut devenir complexe ou non.
  39. 39. Domain Driven Design (DDD) Pourquoi DDD ? Nous aider à développer des logiciels qui s’attaquent à des domaines complexes.
  40. 40. Domain Driven Design (DDD) Mais qu’est ce que c’est ? Ni une architecture, ni une méthode, plutôt une philosophie Priorité 1 : La compréhension du domaine, du métier Priorité 2 : Utilisation de modèles pour représenter tout design complexe (Model Driven Design).
  41. 41. Domain Driven Design (DDD) Appliquer DDD Prérequis : Expert Métier Définir un ”Ubiquitous Language” Modélisation du Domain Model qui utilisera l’UL Utilisation des patterns (Aggregate Roots, Entity, Value Objects etc..) Refactoriser en permanence pour clarifier les concepts du domaine. Pour les gros projets, utilisation des Bounded Context, Context Mapping etc..
  42. 42. Command & Query Responsibility Segregation
  43. 43. CQRS Origine : Issu de la communauté mais popularisé par Greg Young (2009) et d’autres ( Udi Dahan etc..). Pourquoi CQRS ? Réduire la complexité des Domain Model qu’on utilise Faciliter l’extensibilité de l’application (scalability) Améliorer la performance Et tout ce qu’on n’a pas encore découvert …
  44. 44. CQRS Mais qu’est ce que c’est ? Application au niveau architectural de Command Query Separation (CQS) Command : change l’état visible du système void CommanderUnArticle (int idClient, int idArticle); void InscrireNouveauClient (string nom, int age); Query : ne change pas l’état visible du système Solde GetSoldeClient(int idClient) bool GetIsArticleDisponible(int idArticle)
  45. 45. CQRS Architecture “Standard” Presentation DTO Lecture DTO Ecriture Service Lecture Business Domain model Ecriture Data access DB
  46. 46. CQRS Lecture Presentation Ecriture Command Query Service Service Business Domain model Data access Data access DB
  47. 47. CQRS Presentation Command Query Service Service Business Domain model Data access Data access DB DB
  48. 48. CQRS Presentation Command Query Service Service Business Domain model Data access Data access DB DB
  49. 49. Conclusion
  50. 50. Conclusion Si vous n’avez pas tout retenu, pas de panique !
  51. 51. Conclusion Les technologies changent, les grands concepts restent.
  52. 52. Références Patterns of Enterprise Application Architecture (PoEAA) Martin Fowler ( 2003 )
  53. 53. Références DDD Communauté : http://domaindrivendesign.org http://tech.groups.yahoo.com/group/domaindrivendesign/ Livres :
  54. 54. Références CQRS Communauté : http://www.cqrsinfo.com/ http://abdullin.com/wiki/command-query-responsibility-segregation- cqrs.html http://groups.google.com/group/dddcqrs Livre :
  55. 55. Questions ?

×