Présente des patterns et antipatterns pour la conception d'application d'entreprise. Cette présentation contient aussi une introduction à DDD et CQRS

1. palais des
congrès
Paris
7, 8 et 9
février 2012

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

3. Patterns et Antipatterns
d’architecture pour les
applications d’entreprise
7 Février 2012
Riana Rambonimanana
Développeur .NET
Citégestion

4. Agenda
Rappels
Patterns et Antipatterns
Organiser les logiques métier
Accéder aux données
Gérer la distribution
Exemples d’implémentation
Introduction à DDD et CQRS
Conclusion
Questions / Réponses

5. Rappels
Redessinons le contexte

6. Rappels
Application d’entreprise ( * Fowler )
Grande quantité de donnée
Système de persistance
Multi utilisateurs
Logique métier souvent complexe

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

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

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

10. Rappels
Business logic ( logique métier )
Business rules + Workflows
Souvent séparé en deux catégories :
Domain logic
Application logic

11. Patterns et Antipatterns
Réutilisons ce qui marche

12. Les couches
Presentation
Communication interprocessus
Service
Patterns pour
Data Transfer Object (DTO) l’organisation de la
Remote Facade logique métier
Service layer
Patterns pour l’accès aux
Business données
Transaction script
Domain model
Patterns pour les
problèmes de
Data access
distribution
Repository
Data mapper

13. Organiser les logiques métier

14. Pattern : Transaction script
Presentation
Communication interprocessus
Service
Data Transfer Object (DTO)
Remote Facade
Service layer
Business
Transaction script
Domain model
Data access
Repository
Data mapper

15. Pattern : Transaction script
Chaque “use case” est réalisé par une méthode qui exécute toute la
logique correspondante.
GestionCommande
CommanderArticle()
Requête Client Domain Logic
Application Logic
Transaction script
FaireUneReclamation()
Requête Client

16. Pattern : Transaction script
Points forts : Points faibles
 Implémentation facile  Réutilisabilité &
du à l’approche extensibilité limités
procédurale  Ne convient pas aux
 Convient bien aux logiques complexes
logiques simples
Antipatterns fréquents :
 God class
 Spaghetti code
 Copy-paste

17. Pattern : Domain Model
Presentation
Communication interprocessus
Service
Data Transfer Object (DTO)
Remote Facade
Service layer
Business
Transaction Script
Domain model
Data access
Repository
Data mapper

18. Pattern : Domain Model
Les logiques sont partagées par plusieurs objets qui collaborent pour
satisfaire les demandes.
Domain model
Requête Command
Client e Domain Logic
Client
Application Logic
Requête
Client Reclamation

19. Pattern : Domain Model
Points forts : Points faibles
 Exploite le paradigme  Mise en place plus
objet = extensibilité et longue
réutilisabilité  Nécessite de vrais
 Convient bien aux compétences objets
logiques complexes  Mappage complexe
 Testabilité améliorée avec la persistance
(TDD etc.)
Antipatterns fréquents :
 Anemic Domain model

20. Pattern : Service Layer
Presentation
Communication interprocessus
Service
Data Transfer Object (DTO)
Remote Facade
Service layer
Business
Transaction script
Domain model
Data access
Repository
Data mapper

21. 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.
Service Layer
Commande
Requête
Client Domain Logic
Client
Application Logic
Reclamation
Requête
Client

22. Choisir ?
Transaction script
Coût de mise en
place et
maintenance
Domain model
Complexité de la
logique métier

23. Accéder aux données

24. Pattern : Data mapper
Presentation
Communication interprocessus
Service
Data Transfer Object (DTO)
Remote Facade
Service layer
Business
Transaction script
Domain model
Data access
Repository
Data mapper

25. 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 mapper
Domain model
Client Achat Schéma
Client
ClientFidele
Achat
NouveauClient

26. Pattern : Repository
Presentation
Communication interprocessus
Service
Data Transfer Object (DTO)
Remote Facade
Service layer
Business
Transaction script
Domain model
Data access
Repository
Data mapper

27. 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
Data mapper
Repository
DB

28. Gérer la distribution

29. Pattern : Data Transfer Object
Presentation
Communication interprocessus
Service
Data Transfer Object (DTO)
Remote Facade
Service layer
Business
Transaction script
Domain model
Data access
Repository
Data mapper

30. Pattern : Data Transfer Object
Objet servant uniquement à transporter des données et qui a pour but
d’optimiser les échanges lors de communications interprocessus.
Tier 1 Tier 2
Presentation
DTO
Service

31. Pattern : Remote Facade
Presentation
Communication interprocessus
Service
Data Transfer Object (DTO)
Remote Facade
Service layer
Business
Transaction script
Domain model
Data access
Repository
Data mapper

32. Pattern : 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é.
Tier 1 Tier 2
Service Layer
Remote Facade
Preentation
DTO

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

34. Résumé
Presentation
Communication interprocessus
Service
Patterns pour
Data Transfer Object (DTO)
l’organisation de la
Remote Facade logique métier
Service layer
Patterns pour l’accès aux
Business données
Transaction script
Domain model
Patterns pour les
problèmes de
Data access
distribution
Repository
Data mapper

35. Introduction à DDD et CQRS

36. Domain Driven Design

37. Domain Driven Design (DDD)
Créé et formalisé par Eric Evans en 2004 dans son livre éponyme

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

39. Domain Driven Design (DDD)
Pourquoi DDD ?
Nous aider à développer des logiciels qui s’attaquent
à des domaines complexes.

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

41. Domain Driven Design (DDD)
Appliquer DDD
Prérequis : Expert Métier
Définir un ”Ubiquitous Language”
Modélisation du Domain Model qui utilisera l’UL
Utilisation 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..

42. Command & Query Responsibility Segregation

43. 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 …

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

45. CQRS
Architecture “Standard”
Presentation
DTO Lecture DTO Ecriture
Service
Lecture
Business
Domain model Ecriture
Data access
DB

46. CQRS
Lecture Presentation
Ecriture
Command
Query
Service
Service
Business
Domain model
Data
access
Data
access
DB

47. CQRS
Presentation
Command
Query Service
Service Business
Domain model
Data
access Data
access
DB DB

48. CQRS
Presentation
Command
Query Service
Service Business
Domain model
Data
access Data
access
DB DB

49. Conclusion

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

51. Conclusion
Les technologies changent, les grands concepts restent.

53. Références
Patterns of Enterprise Application Architecture (PoEAA)
Martin Fowler ( 2003 )

54. Références
DDD
Communauté :
http://domaindrivendesign.org
http://tech.groups.yahoo.com/group/domaindrivendesign/
Livres :

55. Références
CQRS
Communauté :
http://www.cqrsinfo.com/
http://abdullin.com/wiki/command-query-responsibility-segregation-
cqrs.html
http://groups.google.com/group/dddcqrs
Livre :

56. Questions ?