1ère soirée du Domain Driven Design Users’ Group

LogoDDDFR_thumb

Cet article est un résumé de la première soirée du Domain Driven Design Users’ Group Paris (lancé le 17 février dernier), avec une présentation de Greg Young sur le « Command and Query Responsability Segregation ».
Greg Young commence à nous présenter une architecture très classique dans les développements actuels.

GregYoung1
L’ensemble de cette architecture se base sur une omniprésence de Data Transfert Objects sur l’ensemble des couches. Le comportement de l’application se retrouve dans le client. La montée en charge de l’application est très vite reportée sur la base de données. De plus on arrive très vite à parler avec des verbes techniques (Request DTO, Send DTO). Il n’y pas de modèle du domaine.

GregYoung2GregYoung3

La première étape est de faire la transition entre les deux schémas ci-dessus. Le client ne doit plus travailler uniquement avec des DTOs.
Il doit communiquer au client avec le serveur à travers des commandes. Le service applicatif gère l’objet du domaine.
Cet objet encapsule son état et offre des comportements. On peut ainsi remettre en place les cas d’utilisation ou « user stories ».
L’étape suivante consiste à séparer l’écriture de la lecture car ces deux chemins représentent deux cas d’utilisation différents, avec leurs propres contraintes et besoins.

GregYoung4

Dans le cas de la lecture, il est intéressant de remplacer l’accès à la base de données par un accès rapide et simple à la base de données (direct to DTO). Il reste maintenant le problème de la base de données. Avoir une seule base de données pour les deux cas d’utilisation est une solution simple dans le cas d’un système existant.
Cependant dans la majorité des applications (sauf peut-être certains systèmes financiers), il y a énormément plus de lecture que d’écriture. Il peut être alors très intéressant d’avoir deux bases de données avec un système de duplication maintenant la consistence des données entre les deux bases.

GregYoung5

La base de données en écriture peut être normalisée et la base en lecture dénormalisée.
C’est une très bonne solution quand on pense au problème des rapports qui sont faits sur les bases.

Une réflexion au sujet de « 1ère soirée du Domain Driven Design Users’ Group »

Laisser un commentaire

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