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 site domaindrivendesign.org
• Le livre d'Eric Evans : Domain-driven design, tackling complexity in the heart of software (2004)

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.