Présentation des différents designs applicatifs et de leur implémentation avec Symfony2. Les exemples sont disponibles sur Github : https://github.com/romainkuzniak

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

9. FAVORISER LE CHANGEMENT

10. FAVORISER LE CHANGEMENT

11. QU’EST-CE QU’UN BON
DESIGN ?

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

15. CAS D’UTILISATION

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

24. MVC
https://github.com/romainkuzniak/symfony-mvc

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. Controller
Vue
Model
Pattern Original (UI)

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

29. Entité = POPO
Sprint

30. Sprint Repository

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

39. ARCHITECTURE 3-TIERS
https://github.com/romainkuzniak/symfony-n-tiers

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

44. Entité = POPO
Sprint

45. Sprint Repository

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

49. PRESENTATION LAYER

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

54. DOMAIN DRIVEN DESIGN
https://github.com/romainkuzniak/symfony-ddd

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

64. APPLICATION LAYER

65. Close Sprint
Injection de dépendances
AOP pour la gestion des transactions

66. Close Expected Sprint

67. PRESENTATION LAYER

68. Web Controller

69. Api Controller

70. Command

71. INFRASTRUCTURE LAYER

72. Repository (Implémentation)

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

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. 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É

79. Sprint (Abstract)

80. Sprint (Implémentation)

81. GATEWAY

82. Sprint Gateway

83. Sprint Repository

84. USE CASE

85. Close Sprint

86. Close Sprint Response

87. Close Sprint Response DTO

88. Close Expected Sprint

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

94. RETOUR D’EXPÉRIENCE SUR
OPENCLASSROOMS

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