design applicatif avec symfony2
Post on 15-Jul-2015
3.105 Views
Preview:
TRANSCRIPT
DESIGN APPLICATIF AVEC SYMFONY2
Zoom sur la Clean Architecture
Romain Kuzniak
Responsable Technique OpenClassrooms
@TurnItUpMethod (je débute !)
romain.kuzniak@turn-it-up.org
QU’EST-CE QU’UNE BONNE APPLICATION ?
(Pour moi) Présentation complète
GLOBAL
Projet
Changer le monde
Améliorer la vie des utilisateurs
Etre rentable
Etre fonctionnel
TECHNIQUE
Dernier langage ?
Dernier Framework ?
Code parfait ?
Qu’est ce que du bon code ?
Agilité ?
Tests ?
Continuous Integration ?
Continuous Delivery ?
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) …
CE SONT DES MOYENS PAS UNE FIN
LA FIN C’EST
FAVORISER LE CHANGEMENT
FAVORISER LE CHANGEMENT
QU’EST-CE QU’UN BON DESIGN ?
UN DESIGN QUI FAVORISE LE CHANGEMENT
CAS D’ÉTUDE
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
CAS D’UTILISATION
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
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
DOMAINE
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é
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
RÈGLES APPLICATIVES
Récupérer le sprint
Fermer le sprint
Récupérer les données nécessaires au rapport
DESIGNS
LES PRINCIPAUX TYPES DE DESIGN
MVC
Architecture 3-tiers
Domain Driven Design
Clean Architecture
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
Controller
Vue
Model
Pattern Original (UI)
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
MODEL
Entité = POPO
Sprint
Sprint Repository
WEB CONTROLLER
Règles applicatives
Règles métier
Présentation
Accès aux données
Accès aux données
Règles métier
Règles applicatives
API CONTROLLER
Règles applicatives
Règles métier
Présentation
Accès aux données
COMMAND
Règles applicatives
Règles métier
Présentation
Accès aux données
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 Of The Box avec Symfony2 Full Stack
Avantages Inconvénients
ARCHITECTURE 3-TIERShttps://github.com/romainkuzniak/symfony-n-tiers
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)
Presentation
Controller VueData Business Service
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
DATA LAYER
Entité = POPO
Sprint
Sprint Repository
BUSINESS LAYER
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
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
PRESENTATION LAYER
Web Controller
API Controller
Command
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 Of The Box avec Symfony2 Full Stack
Avantages Inconvénients
DOMAIN DRIVEN DESIGNhttps://github.com/romainkuzniak/symfony-ddd
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
Domain Layer
Application Layer
Presentation
Infrastructure
Entity Repository
Controller
Service
Repository Impl
View
Value Object Service
Service …
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)
…
CONCEPTS
Ubiquitous Language
Model Driven Design
Entities
Value Object
Aggregates
Services
Repositories
Cohabitation avec :
AOP
CQRS
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 …)
DOMAIN LAYER
Issue
Sprint
Repository
APPLICATION LAYER
Close SprintInjection de dépendances
AOP pour la gestion des transactions
Close Expected Sprint
PRESENTATION LAYER
Web Controller
Api Controller
Command
INFRASTRUCTURE LAYER
Repository (Implémentation)
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
CLEAN ARCHITECTUREUSE CASE DRIVEN DESIGN / HEXAGONAL ARCHITECTURE /
PORTS AND ADAPTERShttps://github.com/romainkuzniak/symfony-clean-
architecture
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
Use Case
Controller
Presenter
View Model
View
Request Model
<I>Boundary
Response Model
<I>Boundary
<I>Entity Gateway
<A>Entity
Entity Implementation
Gateway Implementation
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
ENTITÉ
Sprint (Abstract)
Sprint (Implémentation)
GATEWAY
Sprint Gateway
Sprint Repository
USE CASE
Close Sprint
Close Sprint Response
Close Sprint Response DTO
Close Expected Sprint
CONTROLLER
Web Controller
Api Controller
Command
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
RETOUR D’EXPÉRIENCE SUR OPENCLASSROOMS
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é
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
BILAN
Amélioration dans la confiance en l’application
Réussite dans la désormais constance de la productivité
Correspond à notre besoin
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
Evolution de la productivité
MVC n-tiers DDD Clean Architecture
BIBLIOGRAPHIE
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.
MERCI
top related