DDD: où placer les gestionnaires d'événements de domaine?

13

Pourriez-vous me dire votre opinion sur la couche qui est la bonne pour placer les gestionnaires d'événements de domaine dans DDD? Par exemple, j'ai un service d'application pour ajouter un nouveau contrat et j'aimerais envoyer une notification par e-mail à la personne de contact, une fois le contrat ajouté, tout comme le service d'application ou le service de domaine de l'expéditeur de l'e-mail (qui gère l'événement ContractAdded) ou autre chose?

domain-driven-design event Toni
la source

Réponses:

12

Je place les gestionnaires d'événements de domaine dans la couche application.

L'événement de domaine est un moyen de dire aux couches externes (ou au monde extérieur) que quelque chose s'est produit dans la couche de domaine. Que faire de l'événement dépend de l'application. L'application peut informer l'utilisateur des modifications ou appeler un autre domaine pour faire quelque chose. L'application est chargée d'orchestrer les opérations de domaine en réaction aux actions des utilisateurs, aux demandes Web ou aux événements de domaine.

Eugene Khudoy
la source
1
+1 pour la couche application. Dans une conception pub-sub, l'événement de domaine peut activer une logique générique à différents endroits / systèmes / microservices. Si l'un des abonnés est une application modélisée à l'aide de DDD, l'événement déclenche un traitement dans cette application / BC. Ce traitement peut nécessiter une démarcation des transactions, un contrôle d'accès, une coordination qui est généralement effectuée au niveau de la couche application.
Paulo Merson
2

Le livre DDD original (Evans 2004) explique la couche application comme une couche mince qui exerce des objets de domaine en réponse à l'action de l'utilisateur. Les gestionnaires d'événements typiques pour les événements de domaine n'appartiennent donc pas à la couche application.

Il peut être judicieux de placer certains d'entre eux dans la couche domaine, tant que vous ne cassez pas la superposition en créant une dépendance vers le haut.

Si vous avez une couche d'infrastructure qui est en dessous de la couche de domaine, le gestionnaire d'événements ne peut pas être là car il casserait la superposition.

Si vous avez une couche d'adaptateurs au-dessus de la couche de domaine, vous pouvez y créer un gestionnaire d'événements. Découvrez l' architecture hexagonale .

Orn Gudmundur
la source
2

Je place les gestionnaires d'événements de domaine dans la couche Domaine en tant qu'interface de domaine IDomainEventHandler.

Un exemple de gestionnaire d'événements de domaine est une stratégie qui s'abonne à certains événements de domaine afin d'initialiser une nouvelle transaction (par exemple: afin de déclencher une nouvelle commande de domaine), il est donc logique de l'avoir dans la couche Domaine car elle est liée à logique métier.

Nous pourrions penser à un exemple où une commande est confirmée et donc une demande de facture devrait être créée. Nous avons un événement OrderConfirmedEventqui s'est produit. Une politique dans notre domaine serait chargée de s'abonner à cet événement et de créer une commande de domaine RequestInvoicequi sera gérée par le gestionnaire de commandes et traitée par lui en conséquence.

Si nous avions ce gestionnaire d'événements dans la couche application, cela signifierait que la couche application, en plus d'orchestrer les actions de l'utilisateur, exécuterait une logique métier, ce qui semble incorrect.

Mais nous avons

diegosasw
la source