Design applicatif avec symfony2

6 936 vues

Publié le

Présentation des différents designs applicatifs et de leur implémentation avec Symfony2.

Les exemples sont disponibles sur Github :
https://github.com/romainkuzniak

6 commentaires
14 j’aime
Statistiques
Remarques
  • Ca fait du bien de voir une présentation qui montre les différences entre DDD/Clean Architecture/MVC/Ntiers ! Bravo ! Y a t'il une partie "Layer Presentation" dans une "clean architecture" ? En d'autres mots, doit on mettre tous les cas dans les UseCases ? Prenons l'exemple d'une pagination d'une liste de sprint par exemple. Dans une architecture CQRS on délègue en général ça à la partie Query. Devrais-je faire, ici, un use case GetPaginatedSprint ? Il me semble que nous puisque on est en dehors de notre domaine et que ce n'est pas un besoin métier mais que ça fait partie de la couche de présentation. J'ai également hâte de voir la présentation sur le patern View Model justement. Merci pour ta réponse. PS: Veuillez m'excuser pour mon français ;-)
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • @RomainKuzniak Merci ! J'ai hâte de voir cette présentation !
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • @Malian C'est possible, mais pour respecter les principes SOLID, il est préférable de passer par un objet "Model" dédié (découpler la validation, la construction d'une UseCaseRequest à partir de plusieurs formulaires ...). Effectivement, je n'ai pas mis d'exemple dans le repo Github. Je ferai sans doute prochainement une présentation sur le Pattern View Model. Enfin, cela fait beaucoup de classes, mais cela est le prix de la facilitation du changement et de la testabilité. La Clean Architecture a ce coût. (cf la présentation)
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • @RomainKuzniak Merci pour votre réponse rapide ! J'ai effectivement procédé de cette manière ! Ca commence à faire beaucoup de classe mais j'aime tout de même bien l'architecture de l'application. Je me permets une autre petite (?) question. Dans le cas d'un formulaire, imaginons (Edit|Open)SprintType vous lui passez une instance de EditSprintRequestDTO ? Dans ce cas on ne bénéficierait plus du builder mais ça fonctionne tout de même. Après il suffit d'envoyer ce "request" au UseCase adéquat. Peut-être passez vous par une autre méthode ? J'avais pensé également à ceci, http://symfony.com/fr/doc/current/cookbook/form/use_empty_data.html. Encore merci !
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
  • @Malian De Ron L'utilisation de méthode statique pour créer une entité casse la couche d'abstraction. Il faut lui préférer l'usage d'une factory. Dans ce cas, il faut injecter la factory au UseCase, et appeler une méthode make($expectedClosedAt) qui s'occupera de renvoyer une implémentation de Sprint. Cela a également pour avantage de pouvoir injecter n'importe quelle factory, et donc d'instancier n'importe quelle implémentation de Sprint. (Désolé, j'ai bien peur que les saut de ligne ne soit pas possible dans Slideshare)
       Répondre 
    Voulez-vous vraiment ?  Oui  Non
    Votre message apparaîtra ici
Aucun téléchargement
Vues
Nombre de vues
6 936
Sur SlideShare
0
Issues des intégrations
0
Intégrations
131
Actions
Partages
0
Téléchargements
223
Commentaires
6
J’aime
14
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive

Design applicatif avec symfony2

  1. 1. DESIGN APPLICATIF AVEC SYMFONY2 Zoom sur la Clean Architecture
  2. 2. Romain Kuzniak Responsable Technique OpenClassrooms @TurnItUpMethod (je débute !) romain.kuzniak@turn-it-up.org
  3. 3. QU’EST-CE QU’UNE BONNE APPLICATION ? (Pour moi) Présentation complète
  4. 4. GLOBAL Projet Changer le monde Améliorer la vie des utilisateurs Etre rentable Etre fonctionnel
  5. 5. TECHNIQUE Dernier langage ? Dernier Framework ? Code parfait ? Qu’est ce que du bon code ? Agilité ? Tests ? Continuous Integration ? Continuous Delivery ?
 

  6. 6. TECHNIQUE YAGNI (You Ain’t Gonna Need It) KISS (Keep It Simple, Stupid) DRY (Don’t Repeat Yourself) S.O.L.I.D (SRP, OCP, LS, IS, DI) TDD (Test Driven Development) BDD (Behavior Driven Development) DDD (Domain Driven Design) …
  7. 7. CE SONT DES MOYENS PAS UNE FIN
  8. 8. LA FIN C’EST
  9. 9. FAVORISER LE CHANGEMENT
  10. 10. FAVORISER LE CHANGEMENT
  11. 11. QU’EST-CE QU’UN BON DESIGN ?
  12. 12. UN DESIGN QUI FAVORISE LE CHANGEMENT
  13. 13. CAS D’ÉTUDE
  14. 14. CAS D’ÉTUDE Application de gestion d’un tableau agile Cas d’étude : fermeture d’un sprint Manuelle par l’utilisateur via l’interface web ou une API Automatique via un cron
  15. 15. CAS D’UTILISATION
  16. 16. FERMER LE SPRINT - UTILISATEUR Input : Opération explicite de l’utilisateur (web ou api) Scénario : 1. Pour toutes les tâches dont le status est « Done » : Fermer la tâche : Passer le statut à « Close » Ajouter la date de fermeture de la tâche 2. Ajouter la date de fermeture du sprint 3. Sortir toutes les autres tâches du sprint 4. Générer le rapport de sprint Nombre de tâches fermées au cours du sprint Nombre de tâches moyennes fermées au cours de tous les sprints Output : Rapport de sprint
  17. 17. FERMER LE SPRINT - SYSTÈME Input : Opération automatique du système à la date de fin de sprint Scénario : 1. Pour toutes les tâches dont le status est « Done » : Fermer la tâche : Passer le statut à « Close » Ajouter la date de fermeture de la tâche 2. Ajouter la date de fermeture du sprint 3. Sortir toutes les autres tâches du sprint Output : Identifiant du sprint
  18. 18. DOMAINE
  19. 19. VOCABULAIRE Règles métier : comportement lié à une entité à travers toute l’application Règles applicatives : fonctionnalités du domaine, liées à une ou plusieurs entités, dans un contexte donné
  20. 20. RÈGLES MÉTIER Pour toutes les tâches du sprint dont le statut est « Done » : Fermer la tâche : Passer le status à « Close » Ajouter la date de fermeture de la tâche Ajouter la date de fermeture du sprint Sortir toutes les autres tâches du sprint
  21. 21. RÈGLES APPLICATIVES Récupérer le sprint Fermer le sprint Récupérer les données nécessaires au rapport
  22. 22. DESIGNS
  23. 23. LES PRINCIPAUX TYPES DE DESIGN MVC Architecture 3-tiers Domain Driven Design Clean Architecture
  24. 24. MVC https://github.com/romainkuzniak/symfony-mvc
  25. 25. Trygve Reenskaug, Xerox Parc, 70’s GUI pattern à l’origine Etablir une séparation entre les éléments du domaine et les éléments de présentation Principes : Séparer les données, du traitement de la présentation
  26. 26. Controller Vue Model Pattern Original (UI)
  27. 27. Model : Contient les données (Entity) Permet l’accès aux données (Repository) Vue Affiche les données Gère l’interaction utilisateur Controller : Met à jour le model Envoi les données du model à la vue Effectue le traitement métier
  28. 28. MODEL
  29. 29. Entité = POPO Sprint
  30. 30. Sprint Repository
  31. 31. WEB CONTROLLER
  32. 32. Règles applicatives Règles métier Présentation Accès aux données
  33. 33. Accès aux données Règles métier Règles applicatives
  34. 34. API CONTROLLER
  35. 35. Règles applicatives Règles métier Présentation Accès aux données
  36. 36. COMMAND
  37. 37. Règles applicatives Règles métier Présentation Accès aux données
  38. 38. MVC • A l’origine, design pour GUI • Ne propose pas de gestion du domaine • Gestion des règles métier • Gestion des règles applicatives • => pas de réutilisabilité • Pas de séparation de l’infrastructure • Difficile à tester • Indice de changement : BAD • Simple • Séparation Domaine / Présentation • Out OfThe Box avec Symfony2 Full Stack Avantages Inconvénients
  39. 39. ARCHITECTURE 3-TIERS https://github.com/romainkuzniak/symfony-n-tiers
  40. 40. John J. Donovan, Open Environment Corporation, 90’s Grande popularité dans les applications de gestion Objectifs : Créer une application flexible Indépendance entre la présentation, la logique du domaine et l’accès aux données Principe : Séparation en couches Couche de présentation (Presentation Layer) Couche de logique du domaine (Business Layer) Couche d’accès aux données (Data Layer)
  41. 41. Presentation Controller VueData Business Service
  42. 42. Data Layer (Accès aux données) Contient les données (Entity) Permet l’accès aux données (Repository) Business Layer (métier) Effectue le traitement Règles métier Règles applicatives Presentation Layer Controller Vue
  43. 43. DATA LAYER
  44. 44. Entité = POPO Sprint
  45. 45. Sprint Repository
  46. 46. BUSINESS LAYER
  47. 47. Règles applicatives Règles métier Sprint Accès aux données Règles métier Issue Règles métier Sprint Close Sprint
  48. 48. Règles applicatives Règles métier Sprint Accès aux données Règles métier Issue Règles métier Sprint Close Expected Sprint
  49. 49. PRESENTATION LAYER
  50. 50. Web Controller
  51. 51. API Controller
  52. 52. Command
  53. 53. 3-TIERS • Ne propose pas de gestion séparée des règles métier et des règles applicatives • => pas de réutilisabilité indépendante • Pas de séparation de l’infrastructure • Indice de changement : MEDIUM • Séparation Data / Domaine / Présentation • Out OfThe Box avec Symfony2 Full Stack Avantages Inconvénients
  54. 54. DOMAIN DRIVEN DESIGN https://github.com/romainkuzniak/symfony-ddd
  55. 55. Eric Evans, 2004 Objectifs : Gérer des architectures complexes Indépendance avec le framework Indépendance avec l’UI Indépendance avec la base de données Testable Principe : Placer le domaine au centre de l’application
  56. 56. Domain Layer Application Layer Presentation Infrastructure Entity Repository Controller Service Repository Impl View Value Object Service Service …
  57. 57. Presentation Layer Controller Vue Application Layer Règles applicatives Services Domain Layer Règles métiers : Entity Repository (Interface) Infrastructure Layer Service « technique » Repository (Implémentation) …
  58. 58. CONCEPTS Ubiquitous Language Model Driven Design Entities Value Object Aggregates Services Repositories Cohabitation avec : AOP CQRS
  59. 59. Les entités représentent les objets métiers et encapsulent les règles métiers Les services (Application Layer) contiennent les règles applicatives (use cases …)
  60. 60. DOMAIN LAYER
  61. 61. Issue
  62. 62. Sprint
  63. 63. Repository
  64. 64. APPLICATION LAYER
  65. 65. Close Sprint Injection de dépendances AOP pour la gestion des transactions
  66. 66. Close Expected Sprint
  67. 67. PRESENTATION LAYER
  68. 68. Web Controller
  69. 69. Api Controller
  70. 70. Command
  71. 71. INFRASTRUCTURE LAYER
  72. 72. Repository (Implémentation)
  73. 73. DOMAIN DRIVEN DESIGN • Beaucoup de classes • Coût de développement • Pas de SRP dans la couche application • Indice de changement : GOOD • Grande réutilisabilité • Séparation métier / applicatif /présentation • Séparation de l’infrastructure (Framework, DB …) Avantages Inconvénients
  74. 74. CLEAN ARCHITECTURE USE CASE DRIVEN DESIGN / HEXAGONAL ARCHITECTURE / PORTS AND ADAPTERS https://github.com/romainkuzniak/symfony-clean- architecture
  75. 75. Robert C. Martin, 2008 Aggregation des travaux d’Ivar Jacobson (UseCase Driven Design, 1992) ou d’Alistair Cockburn (Hexagonal Architecture, Ports and Adapters, 2005) Objectifs : Gérer des architectures complexes Indépendance avec le framework Indépendance avec l’UI Indépendance avec la base de données Testable Principes : Placer le domaine au centre de l’application Communication entre les couches à travers des abstractions Application des principes S.O.L.I.D Architecture révélant son intention
  76. 76. Use Case Controller Presenter View Model View Request Model <I>Boundary Response Model <I>Boundary <I>Entity Gateway <A>Entity Entity Implementation Gateway Implementation
  77. 77. PRINCIPES Les entités représentent les objets métiers et encapsulent les règles métiers Les Use Case contiennent les règles spécifiques à l’application Les dépendances sont dans le sens opposé au flux de contrôle Grande utilisation des abstractions et des mécanismes associés (Classes abstraites, Interfaces, Factories, Builder, DI …) Seules des structures simples traversent les frontières
  78. 78. ENTITÉ
  79. 79. Sprint (Abstract)
  80. 80. Sprint (Implémentation)
  81. 81. GATEWAY
  82. 82. Sprint Gateway
  83. 83. Sprint Repository
  84. 84. USE CASE
  85. 85. Close Sprint
  86. 86. Close Sprint Response
  87. 87. Close Sprint Response DTO
  88. 88. Close Expected Sprint
  89. 89. CONTROLLER
  90. 90. Web Controller
  91. 91. Api Controller
  92. 92. Command
  93. 93. CLEAN ARCHITECTURE • Encore plus de classes • Coût de développement • Peu de littérature • Indice de changement : EXCELLENT • Grande réutilisabilité • Séparation data / métier / applicatif /présentation • Séparation de l’infrastructure (Framework, DB …) • Principes S.O.L.I.D • Architecture montrant son intention Avantages Inconvénients
  94. 94. RETOUR D’EXPÉRIENCE SUR OPENCLASSROOMS
  95. 95. CONTEXTE Grosse application web Grande complexité fonctionnelle Agilité dans l’essence de l’entreprise Mauvais design de base (hybride entre MVC et 3-tiers) Tests très lents Baisse constante de la qualité et de la productivité
  96. 96. MISE EN OEUVRE Mise en place progressive depuis un an Passage du MVC, au 3-tiers, au DDD puis à la Clean Architecture Difficultés suite à l’absence de documentation Grande exigence demandée aux développeurs
  97. 97. BILAN Amélioration dans la confiance en l’application Réussite dans la désormais constance de la productivité Correspond à notre besoin
  98. 98. DOIS-JE MIGRER VERS LA CLEAN ARCHITECTURE ? Il faut être pragmatique : Quelle taille d’application ? Quelle durée de développement ? Utiliser les principes du refactoring et la BoyScout Rule
  99. 99. Evolution de la productivité MVC n-tiers DDD Clean Architecture
  100. 100. BIBLIOGRAPHIE
  101. 101. Design : Design Patterns:Elements of Reusable Object-Oriented Software. Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides. Addison-Wesley. 1994. http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf Domain Driven Design Domain-Driven Design: Tackling Complexity in the Heart of Software. Eric Evans. Addison-Wesley. 2004. http://dddcommunity.org/ Clean Architecture Object-Oriented software engineering: A use case driven approach. Ivar Jacobson Addison Wesley Professional (1992) http://alistair.cockburn.us/Hexagonal+architecture http://blog.8thlight.com/uncle-bob/2012/08/13/the-clean-architecture.html https://www.youtube.com/watch?v=WpkDN78P884 Clean Code: A Handbook of Agile Software Craftsmanship. Robert C. Martin. Prentice Hall PTR. 2008.
  102. 102. MERCI

×