Laisser le service d'application appeler les deux méthodes
Le service d'application est généralement un excellent point de départ pour cela, mais vous devez toujours essayer de déplacer le comportement le plus près possible de l'entité. Le service d'application joue un rôle d'orchestration et il prépare la scène pour l'exécution du comportement du domaine et en tant que tel, il fournit toutes les dépendances requises. Cependant, lorsque cela est possible, il doit déléguer le comportement au modèle de domaine.
Utilisez l'injection de méthode / double répartition pour injecter le service de domaine dans l'entité, en laissant l'entité faire sa chose, puis laissez-la appeler la méthode du service de domaine (ou l'inverse, en laissant le service de domaine appeler la méthode sur l'entité)
Il s'agit d'une meilleure approche car une plus grande partie du comportement est déléguée à l'entité ou au service de domaine. La manière la plus découplée de mettre en œuvre ceci est de faire en sorte qu'une entité exprime une dépendance à l'égard d'un service en tant que paramètre de la méthode fournissant le comportement en question.
Déclenchez un événement de domaine dans la méthode d'entité, dont un gestionnaire appelle le service de domaine.
Le modèle d'événement de domaine, comme l'expliquent Udi et Evans lui-même, est assez polyvalent et peut être appliqué dans une variété de scénarios. Il y a cependant quelques complications. Tout d'abord, vous devez vous assurer que vous disposez de la portée appropriée dans l'éditeur d'événement de domaine. La plupart du temps, vos gestionnaires d'événements de domaine auront des dépendances et si vous utilisez un conteneur IoC, vous devez vous assurer qu'une bonne instance est injectée. Par exemple, dans une application Web, le[ThreadStatic]l'attribut est problématique pour la portée. Une autre complexité est celle des frontières de transcription. Vous devez prendre en compte les transactions, car si une entité déclenche un événement de domaine, mais qu'une validation ultérieure dans la base de données échoue, tous les gestionnaires d'événements de domaine auront besoin d'un moyen de revenir en arrière, sinon vous finirez par déclencher un événement non valide. Si toutefois vous avez couvert ces bases, les événements de domaine sont un excellent modèle pour encapsuler la logique de domaine au sein des entités elles-mêmes.
La différence entre l'approche 2 et 3 dépend du cas d'utilisation. Un événement de domaine s'applique lorsque vous souhaitez invoquer des comportements supplémentaires en réponse à un événement au passé . Il s'agit d'une contrainte importante, car le gestionnaire d'événements de domaine ne peut pas affecter le comportement de l'entité. D'un autre côté, avec l'approche 2, le service injecté a le potentiel d'affecter le comportement car il est déclaré une dépendance pour ce comportement particulier.