Blog Arolla

TechDays 2012 – partie 2 – patterns et antipatterns

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 :

  1. Comprendre le domaine du métier
  2. 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 !

@pirrmann

Laisser un commentaire

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *