Expliquer ce qu’est un design orienté domain model n’est pas aisé du tout.
C’est plus de l’ordre du bon sens c’est pour cela que ce n’est pas simple à formaliser.
Tant que l’on ne perd pas de vue que son but est la capture du fonctionnel par différentes pratiques de coding, on est bon.

En capturant la totalité du fonctionnel dans le code on réalise le programme ‘parfait’ du point de vue d’un développeur car ça apporte une valeur inestimable en terme de compréhension, donc de reprise de code à des fins de refactoring (un code est amené à bouger car il reflète le changement du business et le niveau de compréhension du business à un instant T).
Comme la perfection n’existe pas il existe des pratiques qui vont nous permettre de l’approcher.

L’exercice consiste à se poser ces questions de façon récurrente :
– mon domain model reflète-t-il assez le fonctionnel ?
– mon domain model est-il indépendant de ma stratégie de persistance ? (ma stratégie de persistance peut changer : SGBD, mémoire vive; les requis fonctionnels doivent subsister)
– mon domain model est-il portable dans un autre langage objet ? (java, c++, c# ; les requis fonctionnels doivent subsister)
– mon domain model reflète-t-il les cas d’utilisation de facon exhaustive ? (La façade de mon application fait partie de mon domain model et doit comporter toutes les méthodes représentant des use cases : savePreferences, updateBalance, deleteAccount, cancelAndReplaceForFolderClosing (même si en interne c’est une méthode générique qui est appelée avec des paramètres différents)).

Il faut différencier les unités de code qui existent à cause d’un besoin technique (remoting, technologie objet, persistance) de celles qui sont présentes quel que soit l’environnement technique. Il faut faire cet exercice mental d’épuration. On dégage ainsi le véritable fonctionnel (le noyau) et on s’y consacre.
Exemple :
L’interface graphique n’appartient pas au domain model, c’est juste la représentation graphique (plus ou moins user friendly) requise par le projet. Les interfaces client lourd, ligne de commande ou web sont totalement interchangeables du point de vue domain model. Elles appèleront la façade en back-end.
Les fonctionnalités graphiques, aussi avancées soient-elles, aident l’utilisateur à utiliser l’applicatif, elles ne définissent pas ce que l’applicatif fait réellement.

La pratique la plus basique de domain modeling est le nommage des entités de code (classes, attributs, méthodes) et l’organisation du code orienté fonctionnel et non technique (nom de package com.company…..user, com.company.accountmonitoring.balancemanagement, etc).
Ainsi les unités de code du domain model ne devraient avoir aucune dénomination technique de type DAO, Service, Manager, Interface, etc. Ces classes n’appartiennent pas au domain model, elle assurent des fonctions techniques : persistance, exposition en remoting (EJB, Webservice, RMI pur, etc), utilisation du queueing pour notifier.
Par contre une méthode de type getUsersWithFullNameAsDefaultSort() sur la facade pourrait représenter un requis précis de l’application.
Exposée en remoting ou pas, utilisée par un client graphique ou pas elle est exploitable. de plus elle révèle plus de choses sur ce qu’elle fait réellement (cf Intention-Revealing Interfaces and methods).
Cette pratique va participer à refléter au maximum le fameux ‘Ubiquitus Language’ d’Eric Evans.

La 2ème pratique est la réflexion autour de la collaboration entre objets, la cardinalité (caractère obligatoire ou pas), la notion d’ordre, la notion d’unicité (qui se traduira en List, Set, Map, etc), les notions de composition (telle entité n’a pas de raison de vivre sans telle autre), d’héritage, de typage.

La 3ème pratique, qui suit le nommage est l’enrichissement en comportement.
Un vrai domain model comporte des classes TRES enrichies en comportement.
En effet si une classe n’est écrite que pour définir des getters et setters elle est pauvre. Sa richesse est définie par les comportements (méthodes) qu’elle expose (éviter les ‘anemic domain model’ d’après Martin Fowler ).
Si une classe a toutes les informations pour définir un comportement, c’est de sa responsabilité de le faire. On fait de l’objet, autant profiter de sa puissance.

Un use case complexe fera participer plusieurs entités à sa décision.
ServiceX {

Collaborator collab1;
Collaborator collab2;
Collaborator collab3;

public EntityZ intentionRevealingMethod() {

if (!collab1.intentionRevealingMethod1() && collab2.intentionRevealingMethod2()) {
return null;
}

if (collab3.intentionRevealingMethod3()) {
throw new BusinessException();
}
// doSomething()
return new EntityZ;
}
}

Cette réflexion autour des responsabilités des objets permet d’enrichir notre domain model et aucun framework de ne le fera pour nous (cf http://weblogs.asp.net/jamauss/archive/2008/07/17/how-to-determine-object-responsibility.aspx).

Pour atteindre ce niveau de coding et l’appliquer systématiquement il faut beaucoup d’expérience (skilled developpers comme le dit Martin Fowler), connaitre des patterns de refactoring (on ne fait pas un domain model optimal du 1er coup) à coupler avec des tests unitaires, une bonne connaissance des principes OO (lire les principes de Robert C Martin, de Martin Fowler, de Rod Johnson, etc), des connaissances de certains designs patterns et des frameworks pour les tâches techniques (spring, hibernate).

Il n’existe pas de façon parfaite de coder, seulement des façons appropriées selon des contraintes définies qui constituent le contexte du projet.
On peut juste faire de notre mieux si on aime faire les choses bien.
Pour moi le DDD c’est l’élégance suprême! Bravo à Eric Evans et à ceux qui y arrivent.
Moi j’essaie tous les jours et je n’obtiens pas leur pourcentage de réussite …
Je reste pourtant persuadé des bienfaits d’une telle pratique.

Encore bravo d’avoir initié une telle discussion!
En tant que fervent adepte du DDD, je t’encourage à poursuivre.

Cordialement,
Louis, fervent adepte de l’objet, du DDD et du TDD.

Toutes les remarques et les critiques sont les bienvenues, voici les réponses et les éclaircissement de divers points :

> Demain je rencontre un client, pourquoi son chef de projet accepterait ce type d’architecture……

Pourquoi une entreprise voudrait utiliser le DDD? Pour développer des applications qui investissent sur son métier. Pour être plus précis, il veut développer des applications qui lui permettent d’implémenter son métier et de mieux comprendre son fonctionnement dans un contexte de logiciel. Par exemple il doit adapter son métier historique au monde de l’e-commercre : vendre sur Internet et vendre en magasin présente chacune des spécificités fonctionnelles. Le DDD peut être une bonne manière de montée en compétence sur ce point.
De plus, il ne veut plus avoir des applications qui sont écrites un instant T et qui 2-3 ans plus tard sont refaites parce que l’on a perdu la cohérence entre ce qui est défini entre les spécifications fonctionnelles et l’implémentation. On se retrouve parfois à réécrire des applications parce que l’on ne sait plus ce qu’elles font réellement.
Enfin, le DDD encourage les équipes techniques et fonctionnelles à travailler ensemble et à s’améliorer ensemble. Ces équipes seront un atout plus tard sur les autres projets.

> Certes tu as mis en évidence l’élément le plus fondamentale Ubiquitus Language mais ta façon d’y arriver se fait un cheveux sur la soupe.

Comme j’ai insisté dans cet article, le DDD a des techniques non intrusives et doivent d’adapter aux organisations existantes. Ainsi il est difficile de dire comment les organisations existantes doivent faire pour communiquer entre elle. J’ai juste fait des propositions afin de « capturer la connaissance fonctionnelle » comme l’interview d’expert fonctionnel par les équipes techniques, des lexiques des termes métiers …
Si tu as un retour de terrain, cela intéresse les lecteurs afin qu’il ait une meilleur compréhension de comment y arriver.

> Beaucoup de personnes autour de moi ont du mal à voir la différence avec le MDA.

Oui c’est assez déroutant tous ces acronymes consonants et qui cachent des concepts fondamentalement différents. Pour te révéler les secrets de fabrication de l’article, à l’origine l’article s’appeler « les faux amis du DDD : TDD, MDA, MDD, MDSD, … ». En discutant en interne de Xebia, le sujet de l’article n’était pas approprié car le sujet reste le DDD. Je reinsiste sur la définition que j’ai proposé : « DDD est une manière de penser la conception autour du code, de collaborer et de communiquer avec les experts fonctionnels ». Tandis que le MDA se base sur des modèles et heuristiques afin de générer le code source de l’application. Même si les prédicats peuvent être semblable la démarche est totalement différents. En DDD, l’implémentation est toujours réalisée par les développeurs. En MDA, l’implémentation est en partie délégué à des outils. Ce qui est déroutant en DDD c’est que ce fameux modèle n’a rien à voir avec un modèle MDA.

> Ton article manque d’exemple concret, tu reste trop en surface pour moi.
> Je me permet d’être très critique sur ce sujet dans la mesure ou tu souhaites t’adresser aux non initiés, et que le sujet est extrement ambitieux.

Je vais proposer une série d’article 2 ou 3 (je ne sais pas encore). Le 2è article sera consacré à un exemple : « Dans un prochain article nous verrons comment concevoir une application avec les techniques proposées par le DDD ». Je n’ai pas pour ambition de supplanter la référence qui reste les travaux d’Eric Evans (son livre, son site http://domaindrivendesign.org/, et son site d’exemple http://dddsample.sourceforge.net/.).

> Par contre ayant l’expérience de projet, je nuancerais ce propos lorsque tu écris que le DDD marche avec toute méthode.
> Les modèles métiers deviennent de plus en plus complexe, la seule façon d’y arriver consiste à travailler avec une approche itérative.

Je suis entièrement d’accord avec toi. Comme dit plus haut le DDD n’est pas intrusif donc il n’impose pas de méthode de travail même si la manière de pensée du DDD se rapproche fortement de la pensée agile.

En espérant avoir pû t’éclairer sur différents points, Nicolas LC (Xebia).

Alexandre, merci pour ces précisions. En effet, une idée des fortes du DDD est la communication CONTINUE sur le fonctionnel tout au long du projet. Ainsi les équipes de développements et fonctionnelles doivent avoir la même connaissance à la fin des développements. Les équipes de développement ne doivent pas laisser de flou sur une implémentation de fonction et remonter toutes ces informations aux experts fonctionnelles. Sinon au fil de développement on a une version « papier » du logiciel, et une version « code » du logiciel, ce qui amènera beaucoup d’interrogation sur le fonctionnement du logiciel et décrébilisera le logiciel et ses équipes.

Fabien, belle initiative et je te souhaite que ça marche. Pour informations Eric Evans a entrepris une initiative semblable http://dddsample.sourceforge.net/.

Et pourquoi implémenter leur exemple avec Qi4J ! . As-tu des expériences avec ce framework, Sébastien?

Alex dP