Présentation des différents designs applicatifs et de leur implémentation avec Symfony2.
Les exemples sont disponibles sur Github :
https://github.com/romainkuzniak
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
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
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
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)
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
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
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 …)
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
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
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.
