insideIT.fr : le blog des architectes IT de SFEIR

Aller au contenu | Aller au menu | Aller à la recherche

Tag - Domain Driven Design

Fil des billets - Fil des commentaires

mardi 16 juin 2009

Domain Driven Design : Eric Evans à l’EPITA le 15 Juin 2009

Le Paris JUG a fait très fort en réunissant plus d’une centaine de personnes à l’EPITA : bien que la conférence ait été annoncée quelques jours à l’avance et que le lieu de rendez-vous ait changé, c’était dans une salle presque comble que nous nous retrouvions hier soir.

La popularité montante du DDD mais aussi le networking y sont probablement pour beaucoup. C’était donc Eric Evans en personne qui a présenté sa session «DDD: putting the model to work» que vous pouvez suivre sur InfoQ Lors de cette session, Eric définit les termes «domain» et «model» :

Domaine : Ensemble de connaissances, d’influences ou d’activités.

Modèle : Ensemble d’abstractions qui décrivent des aspects que l’on a choisi dans un domaine. Le modèle est destiné à résoudre des problèmes liés au domaine qu’il représente.

Eric insiste alors sur le fait qu’un modèle ne doit pas tenter de résoudre tous les problèmes mais doit au contraire être restraint à des scénarios spécifiques. Il cite en exemple une vieille carte de la chine qui était utile à l’époque mais dans le contexte actuel où l’export est au coeur de l’économie chinoise, elle ne répond plus aux nouveaux besoins liés à l’ouverture de la Chine. De même l’exemple du planisphère montre qu’un modèle a tendance à s’éloigner de la réalité.

Le domaine du transport de conteneurs qui est tiré du livre «Domain-Driven Design» est intéressant car un modèle qui marchait bien pour les réservations et le calcul d’itinéraires (un itinéraire est composé de n étapes) n’a pas de sens si on tente de l’appliquer à un contexte d’optimisation des transports (il faut alors définir une structure de graphe).

Il y a toujours plusieurs modèles pour un domaine : il est nécessaire alors de bien délimiter les contextes. Le contexte est un cadre autour d’un mot ou d’une affirmation et qui va déterminer le sens de ce dernier. Un contexte délimité va alors limiter le champ d’application d’un modèle et par conséquent le simplifier et le rendre utilisable.

Enfin le DDD n’est pas toujours une solution appropriée car elle nécessite un dialogue avec les experts du domaine pour réaliser un modèle. Ce processus doit de plus suivre une approche itérative car on est toujours amené à faire du refactoring. Ce dialogue nécessite également de définir un langage commun (Ubiquitous language). Le modèle reprend alors les termes définis par ce langage et reste synchronisé avec ce dernier (implique les refactorings).

Il existe des frameworks encore au stade expérimental qui permettent de faciliter cette démarche. Qi4J (prononcer tchi-for-j) a été mentionné, il se base sur les motifs définis dans le livre d’Érice Evans. Son concepteur fait une comparaison avec un exemple DDD standard dans cette vidéo (Oredev 2008). C’est très prometteur !

Ont également été cités les BRMS, les langages fonctionnels et les DSL qui sont bénéfique à une approche DDD notamment par leur expressivité.

Et aussi dans la catégorie «considérations métaphysiques», pourquoi le terme «domain» plutôt que «business», sachant que l’on utilise souvent le terme «métier» en Français. Selon Éric on ne parle pas toujours d’un métier en DDD. À méditer :)...

Pour en savoir un peu plus, le livre d’Éric «Domain-Driven Design» semble être la référence. Notez également qu’Antonio Goncalves sera au Monde en Tique le 20 Juin pour dédicacer son livre sur Java EE 6.

jeudi 11 juin 2009

Eric Evans au Paris JUG lundi 15 juin

Ce cours post pour vous signaler la venue d'Eric Evans au Paris JUG lundi 15 juin (ce lundi) à 19h30 pour une soirée exceptionnelle dans les locaux de l'EPITA (KB).

Eric viendra parler du Domain Driven Design dont il est le fondateur.

C'est une présentation du niveau des grandes conférences telles que Devoxx ou Jazoon, sauf que vous ne payez ni le transport ni la conférence :-)

Inscriptions ici : http://parisjug.org/xwiki/bin/view/Meeting/20090615

lundi 11 février 2008

[TechDays 2008 - J1] Domain Driven Design par Sami Jaber

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.