Bonjour à tous  

J'ai eu une discussion avec un collègue sur le design de la couche métier/service et plus précisément, sur son contenu.
Nous utilisons le framework Spring mais je suis sûr que ça s'applique à n'importe quel autre framework.
Prenons par exemple un service métier pour un utilisateur.
Nous avons des méthodes simples qui permettent de changer son statut en "ACTIF", "BLOQUE", "REVOQUE".
Cette logique a découlé naturellement du fait que nous utilisons des contrôleurs typés REST avec Spring MVC.
Cela permet d'avoir dans ces méthodes uniquement les règles métiers qui sont liés à ces opérations.

Nous avons eu un souci quand il fallu stocker une date de mise à jour de ce statut car il a fallu repasser sur toutes les méthodes de mises à jour du statut pour changer/ajouter du code.

Lui explique qu'en ayant qu'une seul méthode save et en chargeant l’appelant de faire les modifs qu'il veut sur l'objet à sauvegarder et qu'ensuite la méthode save, ayant toutes les règles métier, la modif ne se serait faite qu'à un seul endroit. Donc facilité de maintenance surtout dans le cas où nous aurions de nouveau ce genre de cas fonctionnel.

Cela me semble moins bien au niveau de l'API du service métier, moins clair pour le programmeur qui doit appeler ce service.
D'un autre côté la multiplication des méthodes rend les évolutions "communes" plus lourdes à effectuer.

Qu'en pensez-vous ?