View
1.070
Download
5
Category
Preview:
DESCRIPTION
Présente des patterns et antipatterns pour la conception d'application d'entreprise. Cette présentation contient aussi une introduction à DDD et CQRS
Citation preview
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 ?
Recommended