102
DESIGN APPLICATIF AVEC SYMFONY2 Zoom sur la Clean Architecture

Design applicatif avec symfony2

Embed Size (px)

Citation preview

Page 1: Design applicatif avec symfony2

DESIGN APPLICATIF AVEC SYMFONY2

Zoom sur la Clean Architecture

Page 2: Design applicatif avec symfony2

Romain Kuzniak

Responsable Technique OpenClassrooms

@TurnItUpMethod (je débute !)

[email protected]

Page 3: Design applicatif avec symfony2

QU’EST-CE QU’UNE BONNE APPLICATION ?

(Pour moi) Présentation complète

Page 4: Design applicatif avec symfony2

GLOBAL

Projet

Changer le monde

Améliorer la vie des utilisateurs

Etre rentable

Etre fonctionnel

Page 5: Design applicatif avec symfony2

TECHNIQUE

Dernier langage ?

Dernier Framework ?

Code parfait ?

Qu’est ce que du bon code ?

Agilité ?

Tests ?

Continuous Integration ?

Continuous Delivery ?

Page 6: Design applicatif avec symfony2

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

Page 7: Design applicatif avec symfony2

CE SONT DES MOYENS PAS UNE FIN

Page 8: Design applicatif avec symfony2

LA FIN C’EST

Page 9: Design applicatif avec symfony2

FAVORISER LE CHANGEMENT

Page 10: Design applicatif avec symfony2

FAVORISER LE CHANGEMENT

Page 11: Design applicatif avec symfony2

QU’EST-CE QU’UN BON DESIGN ?

Page 12: Design applicatif avec symfony2

UN DESIGN QUI FAVORISE LE CHANGEMENT

Page 13: Design applicatif avec symfony2

CAS D’ÉTUDE

Page 14: Design applicatif avec symfony2

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

Page 15: Design applicatif avec symfony2

CAS D’UTILISATION

Page 16: Design applicatif avec symfony2

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

Page 17: Design applicatif avec symfony2

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

Page 18: Design applicatif avec symfony2

DOMAINE

Page 19: Design applicatif avec symfony2

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é

Page 20: Design applicatif avec symfony2

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

Page 21: Design applicatif avec symfony2

RÈGLES APPLICATIVES

Récupérer le sprint

Fermer le sprint

Récupérer les données nécessaires au rapport

Page 22: Design applicatif avec symfony2

DESIGNS

Page 23: Design applicatif avec symfony2

LES PRINCIPAUX TYPES DE DESIGN

MVC

Architecture 3-tiers

Domain Driven Design

Clean Architecture

Page 24: Design applicatif avec symfony2

MVChttps://github.com/romainkuzniak/symfony-mvc

Page 25: Design applicatif avec symfony2

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

Page 26: Design applicatif avec symfony2

Controller

Vue

Model

Pattern Original (UI)

Page 27: Design applicatif avec symfony2

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

Page 28: Design applicatif avec symfony2

MODEL

Page 29: Design applicatif avec symfony2

Entité = POPO

Sprint

Page 30: Design applicatif avec symfony2

Sprint Repository

Page 31: Design applicatif avec symfony2

WEB CONTROLLER

Page 32: Design applicatif avec symfony2

Règles applicatives

Règles métier

Présentation

Accès aux données

Page 33: Design applicatif avec symfony2

Accès aux données

Règles métier

Règles applicatives

Page 34: Design applicatif avec symfony2

API CONTROLLER

Page 35: Design applicatif avec symfony2

Règles applicatives

Règles métier

Présentation

Accès aux données

Page 36: Design applicatif avec symfony2

COMMAND

Page 37: Design applicatif avec symfony2

Règles applicatives

Règles métier

Présentation

Accès aux données

Page 38: Design applicatif avec symfony2

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

Page 39: Design applicatif avec symfony2

ARCHITECTURE 3-TIERShttps://github.com/romainkuzniak/symfony-n-tiers

Page 40: Design applicatif avec symfony2

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)

Page 41: Design applicatif avec symfony2

Presentation

Controller VueData Business Service

Page 42: Design applicatif avec symfony2

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

Page 43: Design applicatif avec symfony2

DATA LAYER

Page 44: Design applicatif avec symfony2

Entité = POPO

Sprint

Page 45: Design applicatif avec symfony2

Sprint Repository

Page 46: Design applicatif avec symfony2

BUSINESS LAYER

Page 47: Design applicatif avec symfony2

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

Page 48: Design applicatif avec symfony2

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

Page 49: Design applicatif avec symfony2

PRESENTATION LAYER

Page 50: Design applicatif avec symfony2

Web Controller

Page 51: Design applicatif avec symfony2

API Controller

Page 52: Design applicatif avec symfony2

Command

Page 53: Design applicatif avec symfony2

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

Page 54: Design applicatif avec symfony2

DOMAIN DRIVEN DESIGNhttps://github.com/romainkuzniak/symfony-ddd

Page 55: Design applicatif avec symfony2

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

Page 56: Design applicatif avec symfony2

Domain Layer

Application Layer

Presentation

Infrastructure

Entity Repository

Controller

Service

Repository Impl

View

Value Object Service

Service …

Page 57: Design applicatif avec symfony2

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)

Page 58: Design applicatif avec symfony2

CONCEPTS

Ubiquitous Language

Model Driven Design

Entities

Value Object

Aggregates

Services

Repositories

Cohabitation avec :

AOP

CQRS

Page 59: Design applicatif avec symfony2

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

Page 60: Design applicatif avec symfony2

DOMAIN LAYER

Page 61: Design applicatif avec symfony2

Issue

Page 62: Design applicatif avec symfony2

Sprint

Page 63: Design applicatif avec symfony2

Repository

Page 64: Design applicatif avec symfony2

APPLICATION LAYER

Page 65: Design applicatif avec symfony2

Close SprintInjection de dépendances

AOP pour la gestion des transactions

Page 66: Design applicatif avec symfony2

Close Expected Sprint

Page 67: Design applicatif avec symfony2

PRESENTATION LAYER

Page 68: Design applicatif avec symfony2

Web Controller

Page 69: Design applicatif avec symfony2

Api Controller

Page 70: Design applicatif avec symfony2

Command

Page 71: Design applicatif avec symfony2

INFRASTRUCTURE LAYER

Page 72: Design applicatif avec symfony2

Repository (Implémentation)

Page 73: Design applicatif avec symfony2

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

Page 74: Design applicatif avec symfony2

CLEAN ARCHITECTUREUSE CASE DRIVEN DESIGN / HEXAGONAL ARCHITECTURE /

PORTS AND ADAPTERShttps://github.com/romainkuzniak/symfony-clean-

architecture

Page 75: Design applicatif avec symfony2

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

Page 76: Design applicatif avec symfony2

Use Case

Controller

Presenter

View Model

View

Request Model

<I>Boundary

Response Model

<I>Boundary

<I>Entity Gateway

<A>Entity

Entity Implementation

Gateway Implementation

Page 77: Design applicatif avec symfony2

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

Page 78: Design applicatif avec symfony2

ENTITÉ

Page 79: Design applicatif avec symfony2

Sprint (Abstract)

Page 80: Design applicatif avec symfony2

Sprint (Implémentation)

Page 81: Design applicatif avec symfony2

GATEWAY

Page 82: Design applicatif avec symfony2

Sprint Gateway

Page 83: Design applicatif avec symfony2

Sprint Repository

Page 84: Design applicatif avec symfony2

USE CASE

Page 85: Design applicatif avec symfony2

Close Sprint

Page 86: Design applicatif avec symfony2

Close Sprint Response

Page 87: Design applicatif avec symfony2

Close Sprint Response DTO

Page 88: Design applicatif avec symfony2

Close Expected Sprint

Page 89: Design applicatif avec symfony2

CONTROLLER

Page 90: Design applicatif avec symfony2

Web Controller

Page 91: Design applicatif avec symfony2

Api Controller

Page 92: Design applicatif avec symfony2

Command

Page 93: Design applicatif avec symfony2

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

Page 94: Design applicatif avec symfony2

RETOUR D’EXPÉRIENCE SUR OPENCLASSROOMS

Page 95: Design applicatif avec symfony2

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é

Page 96: Design applicatif avec symfony2

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

Page 97: Design applicatif avec symfony2

BILAN

Amélioration dans la confiance en l’application

Réussite dans la désormais constance de la productivité

Correspond à notre besoin

Page 98: Design applicatif avec symfony2

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

Page 99: Design applicatif avec symfony2

Evolution de la productivité

MVC n-tiers DDD Clean Architecture

Page 100: Design applicatif avec symfony2

BIBLIOGRAPHIE

Page 101: Design applicatif avec symfony2

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.

Page 102: Design applicatif avec symfony2

MERCI