Design applicatif avec symfony - Zoom sur la clean architecture - Symfony Live
- 1. Design Applicatif avec Symfony Zoom sur la Clean Architecture Romain Kuzniak CTO @ OpenClassrooms
- 2. Nous sommes tous un jour confrontés à un problème de design des applications
- 3. • Rigidité (difficulté de faire les changements) • Fragilité (bugs issus des changements) • Immobilité (réutilisation) • Viscosité (difficulté de faire les bonnes choses, design, environnement, temps de compilation, déploiements, tests…)
- 4. Un bon design est un design qui favorise le changement
- 5. Cas d’étude
- 6. • Application de gestion d’un tableau agile • Cas d’utilisation : fermeture d’un sprint avec génération d’un rapport • Manuelle par l’utilisateur via l’interface web ou une API • Automatique à la fin du sprint via un cron
- 8. • Input : • Opération explicite de l’utilisateur (web ou api) • Scénario : • Récupérer le sprint • Pour toutes les tâches dont le statut est « Done » : • Fermer la tâche : • Passer le statut à « 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 • 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
- 10. Une règle métier est un comportement (généralement lié à une entité) disponible à travers toute l’application
- 11. Tâche • Fermer une tâche • Passer le statut à « Close » • Ajouter la date de fermeture de la tâche Sprint • Fermer le sprint • Pour toutes les tâches du sprint dont le statut est « Done » : • Fermer la tâche • Ajouter la date de fermeture du sprint • Sortir toutes les autres tâches du sprint
- 12. Une règle applicative est une fonctionnalité du domaine, liée à une ou plusieurs entités, dans un contexte donné
- 13. • Récupérer un sprint • Fermer le sprint • Récupérer les données nécessaires au rapport
- 14. • 3 actions • Via le web • Via l’api • Via une commande à la fin du sprint • 2 règles applicatives • Fermer un sprint • Fermer le sprint courant • 2 règles métiers • Tâche : fermer la tâche • Sprint : fermer le sprint
- 15. • 1 critère : capacité de changement • 4 enjeux : • la gestion des règles métiers • la gestion des règles applicatives • le couplage du domaine et de la Vue • le couplage avec l’Infrastructure (accès aux données, framework…)
- 16. MVC
- 17. • Trygve Reenskaug, Xerox Parc, 70’s • GUI pattern à l’origine • Principes : • Séparer les données du traitement de la présentation
- 20. Model
- 23. Controller
- 24. Web Controller Règles applicatives Règles métiers Présentation Accès aux données
- 25. Indice de changement : BAD • Simple • Documenté • Totalement compatible avec Symfony • Aucune gestion des règles métiers • Aucune gestion des règles applicatives • Pas de séparation des données du domaine et de la vue • Couplage fort avec l’infrastructure
- 26. Service Layers
- 27. • 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
- 30. Data layer
- 33. Business layer
- 34. Sprint Service Règles applicatives Règles métiers Tâche Accès aux données Règles métiers Sprint
- 36. Web Controller
- 37. Indice de changement : MEDIUM • Séparation Data / Domaine / Présentation • Documenté • Totalement compatible avec Symfony • Couplage entre les règles métiers et les règles applicatives • Pas de séparation des données du domaine et de la vue • Couplage fort avec l’infrastructure
- 39. • 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
- 41. • Ubiquitous Language • Model Driven Design • Entities • Value Object • Root Aggregates • Services • Repositories • Cohabitation avec : • AOP • CQRS
- 42. Presentation Application Domain Infrastructure Repository Impl Service Impl … Entity Value Object ServiceRepository Service Controller Vue
- 43. Domain Layer
- 44. Tâche
- 45. Sprint
- 48. Sprint Service Injection de dépendances AOP pour la gestion des transactions
- 50. Web Controller
- 53. Indice de changement : GOOD • Séparation Métier / Applicatif / Présentation • Séparation de l’infrastructure (Framework, Base de données…) • Compatible avec Symfony mais un peu de plomberie • Beaucoup de classes • Coût de développement • Pas de SRP dans la couche Application
- 55. • Robert C. Martin, 2008 • 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 • Communication entre les couches à travers des abstractions • Application des principes S.O.L.I.D • Architecture révélant son intention
- 57. Entité
- 60. Gateway
- 61. Sprint Gateway
- 63. Use Case
- 64. Close Sprint
- 66. Close Sprint Response DTO
- 67. Controller
- 68. Web Controller
- 69. Indice de changement : EXCELLENT • Séparation Métier / Applicatif / Présentation • Séparation de l’infrastructure (Framework, Base de données…) • Principes S.O.L.I.D. • Architecture révélant son intention • Compatible avec Symfony • Encore plus de classes • Plomberie • Coût de développement • Peu documenté (mais cela s’améliore)
- 70. Retour d’expérience chez OpenClassrooms Plus de 4 ans après
- 71. • Suppression de la rigidité, fragilité, immobilité, viscosité • Infrastructure, Frameworks et librairie parfaitement découplés • Périmètre des tests adapté • Environnement (déploiements, temps d'exécution des tests…) • Orientation fonctionnelle • Productivité linéaire • Aptitude au changement
- 72. • Courbe d’apprentissage longue et complexe • Peu de documentation • Peu de retours d’expérience • Peu de développeurs formés • Quantité de code • Plomberie • Beaucoup de code pour générer un Use Case
- 73. Devez-vous utiliser la Clean Architecture ?
- 74. Évolution de la productivité MVC n-tiers DDD Clean Architecture
- 75. • Soyez pragmatique • Quelle taille d’application ? • Quelle durée de développement ? • Refactoring
- 77. • Du bootstrap à l’architecture la plus avancée • Tous les composants pour tous les besoins • Standardisés ! • Montées de versions pérennes
- 78. Merci