Je fais mes premiers pas dans la conception basée sur le domaine, j'ai acheté le livre bleu et tout, et je me retrouve à voir trois façons de mettre en œuvre une certaine solution. Pour mémoire: je n'utilise pas CQRS ou Event Sourcing.
Supposons qu'une demande d'utilisateur arrive dans la couche de service d'application. La logique métier de cette demande est (pour une raison quelconque) séparée en une méthode sur une entité et une méthode sur un service de domaine. Comment dois-je procéder pour appeler ces méthodes?
Les options que j'ai rassemblées jusqu'à présent sont les suivantes:
- Laisser le service d'application appeler les deux méthodes
- 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é)
- Déclenchez un événement de domaine dans la méthode d'entité, dont un gestionnaire appelle le service de domaine. (Le type d'événements de domaine dont je parle sont: http://www.udidahan.com/2009/06/14/domain-events-salvation/ )
Je pense que tout cela est viable, mais je ne peux pas choisir entre eux. J'y pense depuis longtemps et j'en suis arrivé à un point où je ne vois plus les différences sémantiques entre les trois. Connaissez-vous des directives sur l'utilisation de quoi?
Réponses:
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.
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.
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.
la source