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
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
7.
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
9.
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…)
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
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
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
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
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)
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