Compte-rendu général de mon parcours de cette année
Mardi 7 février (après-midi)
Première session de l’après-midi : Patterns & Antipatterns d’architecture pour les applications d’entreprises.
Après une petite séance de rappels du contexte et de définitions, on entre dans le vif du sujet, avec une présentation d’une architecture classique en couches, avec identification d’un certain nombre de patterns applicables aux différents niveaux…
| Service | Data Transfer Objects | optimisation des échanges réseau par l’utilisation d’objets légers |
| Remote Façade | optimisation des échanges réseaux par regroupement d’opérations | |
| Service Layer | point d’entrée | |
| Business | Transaction Script | orchestration, implémentation directe |
| Domain Model | représentation du domaine métier, particulièrement adapté au TDD | |
| Data Access | Repository | Isolation du Domain Model et de la persistance |
| Data Mapper | Traduction OO / RDBMS (ORM) |
Pour chaque pattern, les avantages et inconvénients principaux sont listés, puis un choix classique d’architecture est effectué pour présenter un exemple. Évidemment, “Transaction Script” est rapidement écarté…
L’exemple se base sur l’offre Microsoft.Net standard, en utilisant Entity Framework pour mettre en œuvre le Repository, et WCF pour implémenter la Remote Façade. Des DTO sont mis en place pour optimiser les échanges.
Une fois ces patterns abordés, la session prend une autre direction, pour introduire les notions de DDD et CQRS. A ce moment, Cyrille commence à se trémousser sur sa chaise : on parle de DDD, d’Eric Evans, de bible bleue… Les principes fondamentaux sont présentés :
- La vraie difficulté est dans le domaine et non dans les aspects techniques.
- Le design conditionne jusqu'où un projet peut devenir complexe ou non.
En conséquence, les priorités d’une approche DDD sont les suivantes :
- Comprendre le domaine du métier
- Utiliser des modèles pour représenter tout design complexe
La notion d’ “Ubiquitous Language” est utilisée. L’UL est le langage qui permet de définir la sémantique du projet, pour tous les acteurs concernés, sans ambigüité.
On passe ensuite à une rapide présentation de CQRS (Command & Query Responsibility Segregation). Les objectifs de cette démarche sont les suivants :
- Réduire la complexité du modèle
- Améliorer la scalabilité de l’architecture
Le principe de base part d’un constat : il existe deux types d’actions, des “Commands” et des “Queries”.
| Command | Query |
| Modification | Pas de modification |
L’idée est que les actions de type “Query” ne nécessitent pas autant de complexité que les actions “Command”. Il n’est donc pas nécessaire de mettre en place tout le modèle pour ces actions, on peut faire l’économie de certaines couches et réduire la complexité, en améliorant en même temps la performance.
Le temps imparti pour la démo n’a malheureusement pas pu permettre de détailler plus ce point et de montrer des exemples de mise en œuvre. En regrettant que les notions soient abordées aussi rapidement, j’ai tout de même apprécié ces introductions.
La session suivante sera traitée à part car il s’agit d’un sujet qui prend une place particulière : une présentation des Type Providers en F# 3.0, par Don Syme en personne !
Contributeur enthousiaste