Développer des applications d'entreprises ou métiers, de nos jours devient de plus en plus difficile. Les applications sont de plus en plus complexes et les spécifications fonctionnelles instables et changeantes au gré des clients. Pour gérer aux mieux ces difficultés, de bonnes pratiques qui ont fait leurs preuves existent et de nouvelles tendances d’architecture et de design émergent. Que vous soyez développeurs ou architectes, cette session orientée technique vous intéressera car elle vous délivrera différents patterns (et anti-patterns à éviter) pour mieux concevoir l'architecture de vos applications métiers et ainsi mieux absorber les difficultés. On y abordera plusieurs aspects et problématiques récurrentes et comment les résoudre de façon efficace, en illustrant le tout par des exemples d’implémentation possible. Nous y verrons aussi une introduction aux nouvelles tendances d’approche comme le Domain Driven Design (DDD) ou d’architecture comme Command and Query Responsibility Segregation (CQRS) et ce que ces concepts peuvent nous apporter.

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 ?

57. Pour aller plus loin
Prochaines sessions des Dev Camps
Chaque semaine, les 10
Live Open Data - Développer des applications riches avec le
février
DevCamps 2012
16
Meeting protocole Open Data
ALM, Azure, Windows Phone, HTML5, OpenData février
Live
Meeting
Azure series - Développer des applications sociales sur
la plateforme Windows Azure
2012
http://msdn.microsoft.com/fr-fr/devcamp
17
Live Comprendre le canvas avec Galactic et la librairie
février
Meeting three.js
2012
Téléchargement, ressources 21
février
Live La production automatisée de code avec CodeFluent
Meeting Entities
et toolkits : RdV sur MSDN 2012
2 mars Live Comprendre et mettre en oeuvre le toolkit Azure pour
http://msdn.microsoft.com/fr-fr/ 2012 Meeting Windows Phone 7, iOS et Android
6 mars Live
Nuget et ALM
2012 Meeting
Les offres à connaître 9 mars
2012
Live
Meeting
Kinect - Bien gérer la vie de son capteur
90 jours d’essai gratuit de Windows 13 mars
2012
Live
Meeting
Sharepoint series - Automatisation des tests
Azure 14 mars Live TFS Health Check - vérifier la bonne santé de votre
www.windowsazure.fr 2012 Meeting plateforme de développement
15 mars Live Azure series - Développer pour les téléphones, les
2012 Meeting tablettes et le cloud avec Visual Studio 2010
Jusqu’à 35% de réduction sur Visual 16 mars Live Applications METRO design - Désossage en règle d'un
Studio Pro, avec l’abonnement MSDN 2012 Meeting template METRO javascript
20 mars Live Retour d'expérience LightSwitch, Optimisation de
www.visualstudio.fr 2012 Meeting l'accès aux données, Intégration Silverlight
23 mars Live OAuth - la clé de l'utilisation des réseaux sociaux dans
2012 Meeting votre application