Download - Architecture des applications métiers
![Page 1: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/1.jpg)
palais des congrès Paris
7, 8 et 9 février 2012
![Page 2: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/2.jpg)
« Les logiciels c’est comme les cathédrales, d’abord on les construit, et ensuite on prie »
Développeur anonyme
![Page 3: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/3.jpg)
7 Février 2012Riana RambonimananaDéveloppeur .NETCitégestion
Patterns et Antipatterns d’architecture pour les applications d’entreprise
![Page 4: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/4.jpg)
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
![Page 5: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/5.jpg)
RappelsRedessinons le contexte
![Page 6: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/6.jpg)
Rappels
Application d’entreprise ( * Fowler )
Grande quantité de donnée Système de persistance Multi utilisateurs Logique métier souvent complexe
![Page 7: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/7.jpg)
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
![Page 8: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/8.jpg)
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.)
![Page 9: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/9.jpg)
Rappels
Antipatterns
Pratiques courantes mais contreproductives Résulte souvent de patterns mal utilisés Conduit à des coûts élevés de développement
![Page 10: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/10.jpg)
Rappels
Business logic ( logique métier )
Business rules + Workflows Souvent séparé en deux catégories :
Domain logic
Application logic
![Page 11: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/11.jpg)
Patterns et AntipatternsRéutilisons ce qui marche
![Page 12: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/12.jpg)
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
![Page 13: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/13.jpg)
Organiser les logiques métier
![Page 14: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/14.jpg)
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
![Page 15: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/15.jpg)
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
![Page 16: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/16.jpg)
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
![Page 17: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/17.jpg)
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
![Page 18: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/18.jpg)
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
![Page 19: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/19.jpg)
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
![Page 20: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/20.jpg)
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
![Page 21: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/21.jpg)
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
![Page 22: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/22.jpg)
Transaction script
Domain model
Complexité de la logique métier
Coût de mise en place et maintenance
Choisir ?
![Page 23: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/23.jpg)
Accéder aux données
![Page 24: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/24.jpg)
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
![Page 25: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/25.jpg)
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
![Page 26: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/26.jpg)
Presentation
Business
Transaction script
Domain model
Service
Service layer
Remote Facade
Data Transfer Object (DTO)
Data access
Data mapper
Communication interprocessus
Repository
Pattern : Repository
![Page 27: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/27.jpg)
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
![Page 28: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/28.jpg)
Gérer la distribution
![Page 29: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/29.jpg)
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
![Page 30: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/30.jpg)
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
![Page 31: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/31.jpg)
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
![Page 32: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/32.jpg)
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
![Page 33: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/33.jpg)
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)
![Page 34: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/34.jpg)
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
![Page 35: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/35.jpg)
Introduction à DDD et CQRS
![Page 36: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/36.jpg)
Domain Driven Design
![Page 37: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/37.jpg)
Domain Driven Design (DDD)
Créé et formalisé par Eric Evans en 2004 dans son livre éponyme
![Page 38: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/38.jpg)
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.
![Page 39: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/39.jpg)
Domain Driven Design (DDD)
Pourquoi DDD ?
Nous aider à développer des logiciels qui s’attaquent à des domaines complexes.
![Page 40: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/40.jpg)
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).
![Page 41: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/41.jpg)
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..
![Page 42: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/42.jpg)
Command & Query Responsibility Segregation
![Page 43: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/43.jpg)
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 …
![Page 44: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/44.jpg)
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)
![Page 45: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/45.jpg)
CQRS
Presentation
Business
Domain model
Service
Data access
DTO Lecture
DB
DTO Ecriture
Lecture
Ecriture
Architecture “Standard”
![Page 46: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/46.jpg)
CQRS
Presentation
Business
Domain model
Service
Data access
Lecture
Service
Data access
DB
Ecriture
QueryCommand
![Page 47: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/47.jpg)
CQRS
Presentation
Business
Domain model
Service
Data access
QueryCommand
Service
Data access
DBDB
![Page 48: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/48.jpg)
CQRS
Presentation
Business
Domain model
Service
Data access
QueryCommand
Service
Data access
DBDB
![Page 49: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/49.jpg)
Conclusion
![Page 50: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/50.jpg)
Conclusion
Si vous n’avez pas tout retenu, pas de panique !
![Page 51: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/51.jpg)
Conclusion
Les technologies changent, les grands concepts restent.
![Page 52: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/52.jpg)
![Page 53: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/53.jpg)
Références
Patterns of Enterprise Application Architecture (PoEAA) Martin Fowler ( 2003 )
![Page 54: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/54.jpg)
Références
DDDCommunauté :
http://domaindrivendesign.org
http://tech.groups.yahoo.com/group/domaindrivendesign/
Livres :
![Page 55: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/55.jpg)
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 :
![Page 56: Architecture des applications métiers](https://reader036.vdocuments.pub/reader036/viewer/2022062708/558ca2b4d8b42ab3318b4622/html5/thumbnails/56.jpg)
Questions ?