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.