J'ai toujours trouvé la couche de service pour être un endroit logique pour invoquer ce type d'activité - mais comme je l'expliquerai, ce n'est pas où je mis en œuvre il, en tant que tel. Puisque le niveau de service est votre passerelle dans le domaine, vous êtes assuré que quelle que soit la demande qui initie le besoin de ces données, il devra passer par ce point pour y arriver. De plus, le fait que les services parlent à d'autres services est très propre, car ils sont spécifiquement conçus pour nécessiter un effort minimal d'invocation. Vous pouvez exposer la fonctionnalité adéquate dont vous avez besoin dans les référentiels (c'est-à-dire une méthode/un finder/une requête qui pourrait vous donner le nombre d'objets X correspondant aux critères Y) et encapsuler cela dans un appel de service pratique. Non seulement cela vous donne plus de pouvoir pour accomplir facilement des tâches au sein d'un même service, mais vous pouvez également exploiter cette fonctionnalité entre les services pour des besoins plus complexes. Je comprends le souci de mettre la logique métier dans la couche de service, mais en fonction de l'exigence, il s'agit d'une fine ligne entre la logique métier et la logique métier spécifique à l'implémentation. En écrivant un système, il y a souvent des règles qui sont implicites comme étant de la logique métier, mais qui ne correspondent pas. Les contraintes uniques sont ce que j'ai trouvé être l'exemple le plus commun. Rappelez-vous, comme tout le reste dans le dépôt, ce n'est pas une implémentation dans la couche de service, mais une abstraction de ce qui est déjà dans le domaine. Ce que je fais est de placer la "logique" elle-même dans le domaine, généralement sous la forme d'une implémentation de modèle de spécification. Puisque la logique est exécutée dans le référentiel et ne nécessite pas que la couche de service soit modifiée, je suis arrivé à accepter que cela soit complètement acceptable. Vous trouverez que les règles qui s'appliquent aux collections d'entités sont généralement les règles "amusantes". Si vous avez seulement besoin de vérifier que quelque chose est unique avec une collection dans la racine agrégée, c'est assez simple à faire.
J'ai vu des approches où l'objet de domaine a une connaissance du référentiel, et je ne suis pas personnellement un fan. Le référentiel, pour moi, est la définition de la façon dont le domaine va s'interfacer avec la couche de persistance (mais pas toujours l'implémentation). Le fait qu'une entité ait même la connaissance qu'elle a un but plus important que simplement exister complique énormément les choses.
Personnellement, je préfère la deuxième approche. Un autre point important à mentionner est que le référentiel doit être extrait afin que les objets/couches du domaine ne soient pas étroitement couplés au référentiel. –