architecture des 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 access

Repository

Data mapper


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


Presentation

Business

Transaction Script

Service

Service layer

Remote Facade


Data access

Repository

Data mapper


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


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


Presentation

Business

Transaction script

Domain model

Service

Remote Facade


Data access

Repository

Data mapper


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 access

Repository


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 access

Data mapper


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



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 access

Repository

Data mapper


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


Introduction à DDD et CQRS

Domain Driven Design

Domain Driven Design (DDD)

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


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.


Pourquoi DDD ?

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


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


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

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 ?

architecture des applications métiers

Technology