Patterns (et anti-patterns) d’architecture ou comment mieux concevoir ses applications métiers...

palais des congrès Paris

7, 8 et 9 février 2012

« Les logiciels c’est comme les cathédrales, d’abord on les construit, et ensuite on prie »

Développeur anonyme

7 Février 2012Riana RambonimananaDéveloppeur .NETCitégestion

Patterns et Antipatterns d’architecture pour les applications d’entreprise

RappelsPatterns et Antipatterns

Organiser les logiques métierAccéder aux donnéesGérer la distribution

Exemples d’implémentationIntroduction à DDD et CQRSConclusionQuestions / Réponses

Agenda

RappelsRedessinons le contexte

Rappels

Application d’entreprise ( * Fowler )

Grande quantité de donnée Système de persistance Multi utilisateurs Logique métier souvent complexe

Rappels

Architecture

L’ensemble des aspects techniques qui sont importants pour le logiciel Les choix architecturaux influent sur la réussite ou l’échec d’un projet

Rappels

Patterns

Formalisation de solutions courantes à des problèmes récurrents Moyen efficace de partager les connaissances Pratiques éprouvées et considérées comme bonnes Différentes catégories (design, analyse, architecture etc.)

Rappels

Antipatterns

Pratiques courantes mais contreproductives Résulte souvent de patterns mal utilisés Conduit à des coûts élevés de développement

Rappels

Business logic ( logique métier )

Business rules + Workflows Souvent séparé en deux catégories :

Domain logic

Application logic

Patterns et AntipatternsRéutilisons ce qui marche

Les couches

Presentation

Business

Transaction script

Domain model

Service

Service layer

Remote Facade

Data Transfer Object (DTO)

Data access

Repository

Data mapper

Patterns pour les problèmes de distribution

Patterns pour l’organisation de la logique métier

Patterns pour l’accès aux données

Communication interprocessus

Organiser les logiques métier

Presentation

Business

Transaction script

Domain model

Service

Service layer

Remote Facade

Data Transfer Object (DTO)

Data access

Repository

Data mapper

Communication interprocessus

Pattern : Transaction script

Pattern : Transaction script

Chaque “use case” est réalisé par une méthode qui exécute toute la logique correspondante.

Requête Client

CommanderArticle()

FaireUneReclamation()

GestionCommande

Domain Logic

Application Logic

Transaction script

Requête Client

Points forts : Implémentation

facile du à l’approche procédurale

Convient bien aux logiques simples

Points faibles Réutilisabilité &

extensibilité limités Ne convient pas aux

logiques complexes

Antipatterns fréquents : God class Spaghetti code Copy-paste

Pattern : Transaction script

Presentation

Business

Transaction Script

Service

Service layer

Remote Facade

Data Transfer Object (DTO)

Data access

Repository

Data mapper

Communication interprocessus

Domain model

Pattern : Domain Model

Les logiques sont partagées par plusieurs objets qui collaborent pour satisfaire les demandes.

Domain Logic

Application Logic

Requête Client

Requête Client

Commande

Client

Reclamation

Domain model

Pattern : Domain Model

Points forts : Exploite le

paradigme objet = extensibilité et réutilisabilité

Convient bien aux logiques complexes

Testabilité améliorée (TDD etc.)

Points faibles Mise en place plus

longue Nécessite de vrais

compétences objets Mappage complexe

avec la persistance

Antipatterns fréquents : Anemic Domain model

Pattern : Domain Model

Presentation

Business

Transaction script

Domain model

Service

Remote Facade

Data Transfer Object (DTO)

Data access

Repository

Data mapper

Communication interprocessus

Service layer

Pattern : Service Layer

Constitue un point d’entrée unique pour l’extérieur et orchestre les demandes entrantes, mais délègue la majorité des tâches au Domain model.

Commande

Client

Reclamation

Service Layer

Domain Logic

Application Logic

Requête Client

Requête Client

Pattern : Service Layer

Transaction script

Domain model

Complexité de la logique métier

Coût de mise en place et maintenance

Choisir ?

Accéder aux données

Presentation

Business

Transaction script

Domain model

Service

Service layer

Remote Facade

Data Transfer Object (DTO)

Data access

Repository

Communication interprocessus

Data mapper

Pattern : Data mapper

Pattern : Data mapper

Découple entièrement le modèle objet et le modèle de donnée et prends en charge le mapping entre les deux mondes.

Data

m

ap

per

Achat

Domain model

Client

NouveauClient

ClientFideleAchat

Schéma

Client

Presentation

Business

Transaction script

Domain model

Service

Service layer

Remote Facade

Data Transfer Object (DTO)

Data access

Data mapper

Communication interprocessus

Repository

Pattern : Repository

Isole le Domain model de l’accès aux données rendant ainsi le Domain Model indépendant, réutilisable et facilement testable.

Domain model

Rep

osi

tory

Data

m

ap

per

DB

Pattern : Repository

Gérer la distribution

Presentation

Business

Transaction script

Domain model

Service

Service layer

Remote Facade

Data access

Repository

Data mapper

Communication interprocessus

Data Transfer Object (DTO)

Pattern : Data Transfer Object

Pattern : Data Transfer Object

Objet servant uniquement à transporter des données et qui a pour but d’optimiser les échanges lors de communications interprocessus.Pre

senta

tio

nTier 1

Serv

ice

Tier 2

DTO

Presentation

Business

Transaction script

Domain model

Service

Service layer

Data Transfer Object (DTO)

Data access

Repository

Data mapper

Communication interprocessus

Pattern : Remote Facade

Remote Facade

Point d’entrée au système pour les appels distants. Son but sera d’optimiser les échanges réseau en offrant une interface à forte granularité.Pre

enta

tion

Tier 1

Serv

ice

Layer

Tier 2

DTO

Rem

ote

Fa

cad

e

Pattern : Remote Facade

Démo : Exemples d’implémentation« En théorie, il n’y a pas de différence entre la théorie et la pratique, mais en pratique, il y en a » ( Loi de Murphy)

Résumé

Presentation

Business

Transaction script

Domain model

Service

Service layer

Remote Facade

Data Transfer Object (DTO)

Data access

Repository

Data mapper

Patterns pour les problèmes de distribution

Patterns pour l’organisation de la logique métier

Patterns pour l’accès aux données

Communication interprocessus

Introduction à DDD et CQRS

Domain Driven Design

Domain Driven Design (DDD)

Créé et formalisé par Eric Evans en 2004 dans son livre éponyme

Domain Driven Design (DDD)

Constats :

La vraie complexité réside dans le domaine lui même et non dans les aspects techniques. Le design conditionne jusqu’ou un projet peut devenir complexe ou non.

Domain Driven Design (DDD)

Pourquoi DDD ?

Nous aider à développer des logiciels qui s’attaquent à des domaines complexes.

Domain Driven Design (DDD)

Mais qu’est ce que c’est ?

Ni une architecture, ni une méthode, plutôt une philosophie

Priorité 1 : La compréhension du domaine, du métier

Priorité 2 : Utilisation de modèles pour représenter tout design complexe (Model Driven Design).

Domain Driven Design (DDD)

Appliquer DDDPrérequis : Expert MétierDéfinir un ”Ubiquitous Language”Modélisation du Domain Model qui utilisera l’ULUtilisation des patterns (Aggregate Roots, Entity, Value Objects etc..)Refactoriser en permanence pour clarifier les concepts du domaine.Pour les gros projets, utilisation des Bounded Context, Context Mapping etc..

Command & Query Responsibility Segregation

CQRS

Origine : Issu de la communauté mais popularisé par Greg Young (2009) et d’autres ( Udi Dahan etc..).

Pourquoi CQRS ?Réduire la complexité des Domain Model qu’on utilise

Faciliter l’extensibilité de l’application (scalability)

Améliorer la performance

Et tout ce qu’on n’a pas encore découvert …

CQRS

Mais qu’est ce que c’est ?

Application au niveau architectural de Command Query Separation (CQS)

Command : change l’état visible du système

void CommanderUnArticle (int idClient, int idArticle);void InscrireNouveauClient (string nom, int age);

Query : ne change pas l’état visible du système

Solde GetSoldeClient(int idClient)

bool GetIsArticleDisponible(int idArticle)

CQRS

Presentation

Business

Domain model

Service

Data access

DTO Lecture

DB

DTO Ecriture

Lecture

Ecriture

Architecture “Standard”

CQRS

Presentation

Business

Domain model

Service

Data access

Lecture

Service

Data access

DB

Ecriture

QueryCommand

CQRS

Presentation

Business

Domain model

Service

Data access

QueryCommand

Service

Data access

DBDB

CQRS

Presentation

Business

Domain model

Service

Data access

QueryCommand

Service

Data access

DBDB

Conclusion

Conclusion

Si vous n’avez pas tout retenu, pas de panique !

Conclusion

Les technologies changent, les grands concepts restent.

Références

Patterns of Enterprise Application Architecture (PoEAA) Martin Fowler ( 2003 )

Références

DDDCommunauté :

http://domaindrivendesign.org

http://tech.groups.yahoo.com/group/domaindrivendesign/

Livres :

Références

CQRSCommunauté :

http://www.cqrsinfo.com/

http://abdullin.com/wiki/command-query-responsibility-segregation-cqrs.html

http://groups.google.com/group/dddcqrs

Livre :

Questions ?

Chaque semaine, les DevCampsALM, Azure, Windows Phone, HTML5, OpenDatahttp://msdn.microsoft.com/fr-fr/devcamp

Téléchargement, ressources et toolkits : RdV sur MSDNhttp://msdn.microsoft.com/fr-fr/

Les offres à connaître90 jours d’essai gratuit de Windows Azure www.windowsazure.fr

Jusqu’à 35% de réduction sur Visual Studio Pro, avec l’abonnement MSDN www.visualstudio.fr

Pour aller plus loin

10 février 2012

Live Meeting

Open Data - Développer des applications riches avec le protocole Open Data

16 février 2012

Live Meeting

Azure series - Développer des applications sociales sur la plateforme Windows Azure

17 février 2012

Live Meeting

Comprendre le canvas avec Galactic et la librairie three.js

21 février 2012

Live Meeting

La production automatisée de code avec CodeFluent Entities

2 mars 2012

Live Meeting

Comprendre et mettre en oeuvre le toolkit Azure pour Windows Phone 7, iOS et Android

6 mars 2012

Live Meeting

Nuget et ALM

9 mars 2012

Live Meeting

Kinect - Bien gérer la vie de son capteur

13 mars 2012

Live Meeting

Sharepoint series - Automatisation des tests

14 mars 2012

Live Meeting

TFS Health Check - vérifier la bonne santé de votre plateforme de développement

15 mars 2012

Live Meeting

Azure series - Développer pour les téléphones, les tablettes et le cloud avec Visual Studio 2010

16 mars 2012

Live Meeting

Applications METRO design - Désossage en règle d'un template METRO javascript

20 mars 2012

Live Meeting

Retour d'expérience LightSwitch, Optimisation de l'accès aux données, Intégration Silverlight

23 mars 2012

Live Meeting

OAuth - la clé de l'utilisation des réseaux sociaux dans votre application

Prochaines sessions des Dev Camps