Quant on parle de Domain model, bien souvent c'est tout de même en rapport avec la notion d'architecture en couche, avec séparation du métier dans une couche à part. Soit, mais le "pattern" domain model est à la fois beaucoup plus et beaucoup moins.

Un discoure que je vois souvent revenir est de dire que les objets métiers doivent être très bêtes, en n'ayant pratiquement que des accesseurs sur les attributs, et que la couche métier elle, prenait ces objets en entrée. Une couche d'accès aux données les prend pour les faire persister. Finalement ces objets deviennent de bêtes structures de liaison entre une couche métier et une couche d'accès aux données. .

Cette approche est très procédurale, et ne tire finalement en rien partie de la richesse de l'objet, à savoir réunir données et comportement au même endroit. Le pire pourtant, c'est que vu de loin, une telle architecture parait propre puisque le métier est détaché de la persistence. On me répond du coup que c'est nécessaire dans les gros système pour pouvoir exposer des services. Les services peuvent avoir leur utilité, mais ils doivent rester bête et s'appuyer sur un domaine riche de sens. Ils peuvent recevoir et émettre des DTO soit, mais ce n'est pas une raison pour centrer toute notre application autour d'eux. Parce que finalement, un objet qui n'a que des données et pas de comportement, c'est un DTO. Ceux qui les utilisent à outrance ont du oublier la signification du T de DTO: data TRANSFER object. Ils servent à transmettre nos objets d'un système à un autre, mais à l'intérieur même du système, ils n'ont aucun sens.
Fowler pour décrire ce phénomène parle "d'Anemic Domain Model"


Le tout est finalement est de bien imaginer ce qu'est un modèle du domaine. Ce n'est pas une sorte de pool de DTO dans lesquels on peut piocher en fonction de ce qu'on veut faire persister ou transmettre, mais c'est une forme de réalité. Un objet vit dans le domaine du moment que l'on fait un new, et il y restera jusqu'à qu'on fasse appel à un delete sur sa repository. Entre temps, le fait qu'il soit déshydraté et réhydraté depuis une base est purement technique et secondaire. Le modèle est une sorte de réalité vivante riche de sens où les objets interagissent entre eux, vivent, se modifient. Pour des raisons purement technique, nous synchronisons de temps temps l'état dans une base, mais dans un monde utopique, le model pourrait vivre en mémoire éternellement. Toute la philosophie d'un mapper O/R justement est de réussir cette synchronisation, en convertissant des concepts objets en concepts relationnels. J'ai tendance à penser que toute autre utilisation est finalement un détournement de la philosophie d'origine d'un mapper. C'est non seulement un détournement, mais en plus de la complexité pour rien. Un model du style "une classe une table" ne nécessite en rien un mapper dont tout l'intérêt réside justement dans sa capacité à nous permettre d'utiliser la puissance de l'objet tout en le faisant persister en base. Pour être plus précis, je devrais parler de MetaData mapping, qui consiste donc à décrire ailleurs que dans la classe comment la faire persister. C'est ce que font notamment les fichiers mapping d'hibernate (et du coup, utiliser hibernate sans utiliser les fichiers mapping est également dans la majorité des cas une mauvaise compréhension de l'intérêt de l'outil).

La séparation en couche ne suffit pas, pour pouvoir réellement écrire un tel modèle, il faut qu'il soit ignorant de sa persistance, qu'il y ait le moins d'intrusions possible du monde extérieure. Pourtant nombre de framework que ce soit de mapping O/R, d'IoC, MVC sont très intrusifs, et leur emploi conditionne la manière dont nous écrivons le métier. Pire, certains d'entre eux réduisent la testabilité de notre modèle en couplant tellement tout au runtime qu'il devient très difficile d'introduire des mocks. Ces frameworks pourtant vantent leur approche par couche. Je dis que ceux sont de faux amis. Prenez par exemple ActiveRecord. Il faut non seulement inclure une référence dans notre model à ActiveRecord pour s'en servir, mais en plus tout le système d'attributs que l'on place dans nos classes couple énormément notre model à ce système de persistance tant philosophiquement que physiquement. Nous ne sommes pas du tout abstrait de la persistence avec un tel système, et il sera relativement difficile à l'avenir de libérer notre model d'ActiveRecord.

C'est pourquoi je m'insurge quand j'entends dire que l'architecture d'une application est forcée par la technique. Ce n'est pas parce que je fais du .net que j'utilise ces immondices de DataSet et que je fais du rad. Il devrait en être de même en java. Après explications j'ai vraiment l'impression que les EJB malgré leur apparente propreté ne sont finalement qu'un moyen de faire du rad, et ils ont donc tous les problèmes qu'engendre cette approche (j'en parlais là)


Bon pour conclure, je tiens à rappeler un fait que j'oublie souvent trop moi-même, à savoir que l'approche par domaine n'est pas LA silver bullet. Il existe d'autres approches avec leurs avantages et leurs inconvénient tout comme l'approche par domaine. Je me permettais juste ici de souligner quelques fausses vérités que j'ai pu croiser.