Quelles méthodes je peux mettre dans mes « objets du domaine » ?
Par batmat le vendredi 21 décembre 2007, 14:49 - Technique - Lien permanent
Gavin King, le créateur du projet Hibernate, dont le hobby est maintenant devenu Seam, a récemment publié un billet intéressant sur ce sujet.
Souvent, la question se pose : quelles méthodes doit-on modéliser dans un objet métier ? Concrètement, où dois-je mettre mon code métier ? Par exemple, est-ce que la méthode de sauvegarde d'une facture doit se trouver dans l'objet Facture lui-même ? Si je veux récupérer le nombre de clients d'une facture, dois-je mettre la méthode dans la Facture, etc. ?
Gavin a formulé d'une façon très concise une règle à laquelle je souscris totalement :
the domain model (entity classes) are the most reusable classes in my codebase
[...]
In particular, I would never write code that calls out to external services, or accesses the database, or calls an EJB/Seam/Spring component in my entity class. I want my domain model to be completely self-contained!
So anytime you find yourself wishing that entities supported injection, or find yourself writing a JNDI lookup in a method of an entity, please consider that your domain model is no longer self-contained, and will be less reusable in different execution environments.
Rien de plus à ajouter.
Commentaires
Un petit quelque chose de plus à ajouter quand même
Gavin dit que ses méthodes de domaine ne s'intéressent qu'à l'état des objets du domaine et aux autres classes du domaine.
Il y a un cas (courant) qui pose problème : une règle de gestion s'appuie sur une donnée de référence dont je dois tester la valeur, mais la classe de cette donnée ne peut être implémentée par un enum (car son domaine de valeur varie).
Je dois donc, dans ma méthode, accéder à la valeur en question par son nom (ce qu'on fait quand on utilise une valeur particulière d'un enum dans une méthode).
En tout état de cause, il faudrait une dépendance explicite vers un DAO "particulier" accédant aux données de référence. C'est très vilain et contraire à ce que Gavin explique
Une suggestion ?
À côté de ton objet en question, je suppose que tu as un service qui peut en gérer tout ou partie ? À mon sens, dès qu'on parle de règle de gestion, c'est justement qu'on sort du cadre des domaines à coder directement dans l'objet du domaine.
Si c'est bien ce qu'on désigne généralement par "code métier" dont tu parles, alors je confirme. Le code métier n'a rien à faire dans l'objet du domaine, mais bien dans le service/la couche service.