Vous aimez ce que vous lisez sur ce blog ?
Envie d'aller plus loin avec véritable formation d'expertise en Java ?
Venez suivre ma formation Masterclasse Expertise Java !

"Même un développeur experimenté a besoin de continuer à apprendre. Et dans cette formation... j'ai appris beaucoup !" - A.G., Java Champion

Prochaines sessions inter-entreprises : 28-31 mars 2017 / 13-16 juin 2017
Sessions intra-entreprises sur demande.
Inscrivez-vous vite !

Paris JUG "Domain-driven design" : compte-rendu

Lundi soir se tenait une soirée exceptionnelle du Paris JUG sur le Domain-driven design, profitant de la présence d'Eric Evans sur Paris. En voici un rapide compte-rendu ; pour creuser davantage la question, je vous recommande :

Le domaine

Tout d'abord, il convient de définir ce terme : le "domaine" représente la sphère d'informations et d'activités qui définissent un univers particulier (souvent professionnel, on peut donc également parler de Business Driven Design).
Appréhender toutes les subtilités d'un domaine métier est une tâche difficile lorsqu'on intervient sur un projet. C'est pourtant une étape critique : l'inadéquation du produit aux besoins de ses utilisateurs constitue la première cause d'abandon ou de non-utilisation des projets informatiques.

En tant que "techniciens", nous devons faire l'effort de nous approprier le vocabulaire métier afin de communiquer efficacement avec les "fonctionnels". De manière officieuse, cela permet également de les tenir à l'écart de tout aspect technique, pour leur propre bien - et le nôtre (qui n'a jamais pesté contre une MOA s'improvisant experte en UML et en ergonomie web ?).
La première étape consiste à identifier les termes significatifs et leurs synonymes, ainsi que leur contexte d'utilisation ; la seconde, à déterminer les use-cases les plus importants et les plus courants, afin de borner le périmètre. Il est d'ailleurs recommandé de s'appuyer sur de véritables cas concrets plutôt que d'imaginer un use-case abstrait, parfait, qui ne reflète pas les problèmes ou imprévus rencontrés en situation réelle.

Le modèle

Parlons maintenant du "modèle".
A partir des connaissances fonctionnelles (informations) et des use-cases (activités), on peut extraire une représentation réaliste des processus métiers qui devront être informatisés. Mais attention, il n'existe pas un modèle, mais des modèles, chacun mettant en valeur une facette spécifique du domaine et possédant des avantages et des inconvénients en fonction de son contexte d'utilisation.

Eric a cité l'exemple de la modélisation des trajets des bateaux porte-containers. En les représentant sous la forme de segments, il est possible de dérouter les navires facilement (il suffit de remplacer un segment par un autre), mais les opérations portuaires sont difficiles à prendre en compte ; la modélisation sous la forme de simples points d'arrêt résout ce problème de manière élégante, mais complique la gestion des trajets (caps, vitesses...).

On peut maintenant en déduire la définition du modèle : un modèle est une abstraction décrivant de manière sélective un aspect particulier du domaine métier, en vue de résoudre un problème spécifique au sein de cet univers.

N'oubliez pas la technique

Le dernier point important de cette méthode est qu'il faut tout de même vérifier régulièrement si le modèle proposé est facilement implémentable. Il faudra parfois faire des compromis entre la facilité de résolution des problèmes métier et la facilité/performance de la solution technique correspondante.

Le cas des DSL (Domain Specific Languages) a été abordé, pour conclure qu'ils étaient intéressants sur le plan fonctionnel mais encore trop difficiles à mettre en place et maintenir (définition de la grammaire, génération du compilateur/parseur...) pour justifier leur usage.
On notera également une rapide allusion au framework qi4j ("chi for J"), dont le nom avait déjà été prononcé au cours d'un Barcamp. A surveiller, donc.

Conclusion

La soirée était sympa et intéressante, bien organisée malgré le délai ridicule (moins d'une semaine). On remerciera l'équipe du Paris JUG et l'Epita pour cette réactivité, cela fait toujours plaisir de voir des gens qui se bougent pour la bonne cause. On remerciera également les relais d'information (bloggers, twitters, sponsors...) qui ont réussi à attirer plus de 110 personnes dans l'amphi (et 160 inscrits à l'origine).
Quant à Eric Evans, il est plutôt bon orateur et l'heure et demie est passée bien rapidement : plan clair et anecdotes intéressantes, slides épurés, et accent compréhensible, même si quelques personnes m'ont confié avoir eu du mal à suivre certains passages.

Sur le fond maintenant, de mon point de vue, le Domain-driven design n'est clairement pas la révolution qu'annoncent certains ; il ne s'agit que de la formalisation et du dépoussiérage de certaines bonnes pratiques qui devraient pourtant sembler évidentes à tous les consultants / développeurs : écoute et accompagnement du client, sens du service, et pragmatisme technique. A leur décharge, il faut dire que les entreprises leur laissent rarement le loisir d'interagir directement avec leurs clients, et plus rarement encore lors des phases de lancement des projets... Mais d'après mon expérience, il faut savoir se battre pour faire son métier honnêtement, quitte à bousculer un peu les hiérarchies et les carcans rouillés ; c'est un combat qui mérite d'être mené, car le résultat est toujours très satisfaisant pour les deux parties.


EricEvans.jpg


Commentaires

1. Le mardi 16 juin 2009, 09:08 par Slim Tebourbi

Meme si c'est des notions anciennes et 'evidentes' comme tu dit, on en est souvent trés loin dans la realité. Le stereotype du bean anémique/DAO/super service qui fait tout et rien est archi dominant dans presque toutes les applis.

2. Le mardi 16 juin 2009, 09:54 par Olivier Croisier

L'un n'empêche pas l'autre.
On peut très bien appliquer le DDD pour le recueil et la formalisation des spécifications et la modélisation de la couche domaine, et réaliser ensuite l'application selon l'architecture classique en couches (avec ses avantages et inconvénients).
De plus, je ferai remarquer que le syndrôme du bean anémique est un tout autre problème encore, qui de mon point de vue est surtout dû aux contraintes imposées par certains frameworks (notamment Spring et Hibernate).

3. Le mardi 16 juin 2009, 12:49 par Romain

Bonjour,
J'ai été un peu déçu par la prez' . La valeur et la "nouveauté" de DDD sont pour moi plutôt dans les patterns entity, value object, aggregats, repository, etc.. que dans ce qui nous a été présenté : langage universel, accès au métier, limites des modèles etc.. Du coup, un peu de frustration, mais ça n'engage que moi :)

4. Le mardi 16 juin 2009, 21:24 par Slim Tebourbi

De plus, je ferai remarquer que le syndrôme du bean anémique est un tout autre problème encore, qui de mon point de vue est surtout dû aux contraintes imposées par certains frameworks (notamment Spring et Hibernate).

je suis pas du tout d'accord avec toi olivier. Spring et Hibernate sont au contraire trés utiles pour mettre en place des "domaines riches". Tu peux meme retrouver certaines notions de DDD qui y sont présentées, mais pas assez mises en evidence par fois. Par exemple pour ce qui est de la persistence hibernate reperend trés bien les patterns Entity et ValueObject, et permet assez facilement de creer des objets non anémiques. Quand a Spring, regardes ce qui a été rajouté dans la version 2.5.x comme l'annotation @Configurable pour injecter des beans dans "les objects du domaines" ou carrément @Repository...

5. Le mardi 16 juin 2009, 21:32 par Jérémie

La conférence était effectivement faite pour présenter les notions de design et principalement de bounded context. Difficile à saisir, il faut vraiment sentir le besoin en se confrontant à un projet nécessitant ces concepts.

@olivier, quand on place le domaine comme couche de base, on obtient plutot une architecture en peau d'onion. Toutes les dépendances (et en particulier les accès à la base) sont implementées dans les couches hautes. C'est un bon moyen d'arriver à la Persistence Ignorance à mon avis. Le domaine ne doit avoir aucune dépendence technique.
@Romain, malheureusement pour toi, Eric Evans aurait presque préférer ne pas mettre ces patterns dans le livre.. Pour lui ce ne sont que des patterns objets pour améliorer la qualité du code objet et avoir une meilleure Persistance Ignorance, mais ils ne sont pas spécifique au Domain Driven Design. Du coup, beaucoup on cru qu'appliquer ces patterns en était le but. Mais ces patterns peuvent aussi etre utilisé en CRUD, ce qui ne va pas du tout dans le sens du DDD.

6. Le mercredi 17 juin 2009, 09:41 par trungsi

Quelqu'un a t - il utilisé @Configurable de Spring? Est ce que ça fonctionne avec des objets désésialisés (pense au cache sur disque)?

7. Le mercredi 17 juin 2009, 09:50 par Olivier Croisier

D'après la documentation de Spring (§6.8.1) :
In essence the aspect says "after returning from the initialization of a new object of a type annotated with @Configurable, configure the newly created object using Spring in accordance with the properties of the annotation". In this context, initialization refers to newly instantiated objects (e.g., objects instantiated with the 'new' operator) as well as to Serializable objects that are undergoing deserialization (e.g., via readResolve()).

Donc oui, cela semble fonctionner avec des objets (dé)sérialisés.

8. Le mardi 23 juin 2009, 21:09 par Slim Tebourbi

jetez un coup d'oeil sur cette article : New Improvements in Domain Object Dependency Injection Feature

Ajouter un commentaire

Le code HTML est affiché comme du texte et les adresses web sont automatiquement transformées.