Après une rapide présentation de la 4ème édition du symposium DNG 2008 qui se déroule aujourd'hui, Sami a tenté de nous présenter le "Domain Driven Design" en une petite heure. Le DDD, pour faire court, est un design qui est apparu pour la première fois en 2003 sous la plume d'Eric Evans. Pour ceux qui par paresse ou manque de temps ne peuvent pas lire les 500 pages et quelques du livre d'Eric Evans, InfoQ en a résumé les principales lignes : DDD-quickly

Résumé de la présentation

Point de départ : de nouvelles technos comme Link modifient la manière de penser l'architecture en couches.

Architecture n-tiers traditionnelle

Les différentes couches sont Présentation, Services (use case fonctionnel), Domaine (objets métier) et Accès aux données. Les traitements métier sont concentrés dans la couche service. Par conséquent, le code est souvent procédural, peu objet, et dur à tester. Ceci pose également des problèmes de redondance et donc de maintenance du code.

Ceci se traduit par des méthodes de manipulation sans état, statiques, et des objets qui ne sont qu'une liste de champs avec getters setters. Les méthodes qui manipulent logiquement les données internes d'un objet ne se retrouvent pas dans l'objet mais dans une classe à part qui contient les méthodes statiques.

Une logique objet voudrait que les objets contiennent eux-mêmes les méthodes capables de manipuler leurs variables d'instances.

Domain Driven Design

Les différentes couches sont Présentation, Domaine, Application et Infrastructure. Le principe du DDD est de faire graviter la logique métier autour de la couche Domaine, autour des objets. Les objets contiennent le code métier, et font eux-mêmes les appels nécessaires au déroulement du service (appel à la couche service, appel à la base via la couche accès aux données, etc.)

En conséquence, ils constituent le point d'entrée du service et orchestrent l'interaction entre les couches. De fait, on ne peut plus faire simplement de l'injection de dépendance dans les objets, puisque cela suppose une manipulation des objets depuis une autre couche. Le "remplissage" des objets, leur instanciation, va donc être faite soit par de simples appels aux constructeurs, soit via des "Factory", appelées par les objets eux-mêmes.

Le mécanisme de manipulation des objets peut s'avérer complexe si l'agrégat d'objets est gros, si le nombre d'objets manipulés est important. Pour gérer cette manipulation, on va considérer cet agrégat d'objet comme une entité munie d'un objet racine, point d'entrée de l'agrégat.

Il peut s'avérer lourd de procéder à une instanciation et une injection de dépendances sur toute une arborescence d'objets lorsque le seul but est de récupérer des valeurs en base liées à ces objets. C'est là qu'interviennent les Value Objects, objets immuables qui autorisent simplement l'accès à l'information contenue dans ces objets en base.

Autre conséquence du DDD : la couche d'accès aux données classique disparaît : la couche des services n'est plus là pour appeler la couche accès : les données sont donc remontées autrement, via les "Repositories". Les repositories permettent d'effectuer les opérations de recherche en base.