Design applicatif avec symfony2
- 1. DESIGN APPLICATIF AVEC SYMFONY2 Zoom sur la Clean Architecture
- 2. Romain Kuzniak Responsable Technique OpenClassrooms @TurnItUpMethod (je débute !) romain.kuzniak@turn-it-up.org
- 3. QU’EST-CE QU’UNE BONNE APPLICATION ? (Pour moi) Présentation complète
- 4. GLOBAL Projet Changer le monde Améliorer la vie des utilisateurs Etre rentable Etre fonctionnel
- 5. TECHNIQUE Dernier langage ? Dernier Framework ? Code parfait ? Qu’est ce que du bon code ? Agilité ? Tests ? Continuous Integration ? Continuous Delivery ?
- 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. CE SONT DES MOYENS PAS UNE FIN
- 8. LA FIN C’EST
- 12. UN DESIGN QUI FAVORISE LE CHANGEMENT
- 13. CAS D’ÉTUDE
- 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
- 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. 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. DOMAINE
- 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. 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. RÈGLES APPLICATIVES Récupérer le sprint Fermer le sprint Récupérer les données nécessaires au rapport
- 22. DESIGNS
- 23. LES PRINCIPAUX TYPES DE DESIGN MVC Architecture 3-tiers Domain Driven Design Clean Architecture
- 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
- 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. MODEL
- 31. WEB CONTROLLER
- 32. Règles applicatives Règles métier Présentation Accès aux données
- 33. Accès aux données Règles métier Règles applicatives
- 34. API CONTROLLER
- 35. Règles applicatives Règles métier Présentation Accès aux données
- 36. COMMAND
- 37. Règles applicatives Règles métier Présentation Accès aux données
- 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
- 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. Presentation Controller VueData Business Service
- 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. DATA LAYER
- 46. BUSINESS LAYER
- 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. 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
- 50. Web Controller
- 51. API Controller
- 52. Command
- 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
- 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. Domain Layer Application Layer Presentation Infrastructure Entity Repository Controller Service Repository Impl View Value Object Service Service …
- 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. CONCEPTS Ubiquitous Language Model Driven Design Entities Value Object Aggregates Services Repositories Cohabitation avec : AOP CQRS
- 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. DOMAIN LAYER
- 61. Issue
- 62. Sprint
- 63. Repository
- 65. Close Sprint Injection de dépendances AOP pour la gestion des transactions
- 68. Web Controller
- 69. Api Controller
- 70. Command
- 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. CLEAN ARCHITECTURE USE CASE DRIVEN DESIGN / HEXAGONAL ARCHITECTURE / PORTS AND ADAPTERS https://github.com/romainkuzniak/symfony-clean- architecture
- 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
- 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. ENTITÉ
- 81. GATEWAY
- 82. Sprint Gateway
- 84. USE CASE
- 85. Close Sprint
- 87. Close Sprint Response DTO
- 89. CONTROLLER
- 90. Web Controller
- 91. Api Controller
- 92. Command
- 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
- 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. 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. BILAN Amélioration dans la confiance en l’application Réussite dans la désormais constance de la productivité Correspond à notre besoin
- 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. Evolution de la productivité MVC n-tiers DDD Clean Architecture
- 100. BIBLIOGRAPHIE
- 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. MERCI