DDD - quelle couche DTO doit être implémentée
J'apprends DDD donc excuses si ma question est naïve. Je pense que j'ai besoin d'utiliser un objet de transfert de données local afin d'afficher des données aux utilisateurs car de nombreuses propriétés ne font partie d'aucun objet d'entité/valeur.
Cependant, je ne sais pas où ce DTO doit être implémenté - dans une couche de domaine ou dans une couche de service d'application. L'implémentation DTO semble faire partie du domaine, mais cela signifie que lorsque je crée une collection de DTO dans la couche service et la transmets à une couche présentation, je dois référencer la couche domaine dans la couche présentation, ce qui semble incorrect.
Quelle est la bonne façon de mettre en œuvre DTO en utilisant les principes DDD?
Placez-le dans Domain Service Layer. DTO est une sortie de cette couche, cela a du sens si vous la définissez là.
Ne placez pas votre DTO dans la couche de domaine. La couche de domaine ne se soucie pas des choses en dehors de sa couche.
EDIT: la couche de service de domaine est communément appelée couche "service d'application"
Yorro a raison sur l'endroit où placer le DTO mais je vous encourage à éviter "l'état d'esprit DTO". Cette façon de penser entre en collision avec la façon de penser DDD.
Penser à "J'ai besoin d'un DTO ici", c'est penser à la représentation technique (comme le dit plalx); c'est un niveau d'abstraction trop faible. Essayez un niveau d'absorption plus élevé et pensez à votre domaine, aux tâches de l'utilisateur et à votre interface utilisateur.
Avez-vous besoin de voir les données de l'utilisateur? Apportez-le à l'interface utilisateur via un service d'affichage qui renvoie une classe YourViewInfo spécifique.
Avez-vous besoin d'envoyer des données à un service pour effectuer une tâche? Envoyez-lui une classe TaskMessageInfo spécifique ou une classe Command spécifique.
Lorsque vous commencez à modéliser les internes de ces classes, c'est à ce moment que vous devriez commencer à penser à sa représentation technique; alors vous pourriez arriver à la conclusion qui pourrait être, c'est-à-dire, les classes DTO pour plus de commodité.
Penser de cette façon vous aide à modéliser le système et ne déclenche pas de questions comme
Où mettre ou appartient cette chose?
DTO et Domain sont des couches différentes.
.
Consultez les articles suivants pour approfondir le DTO et la superposition:
De tels DTO qui sont exposés au monde extérieur font partie d'un contrat. Selon leur forme, un bon endroit pour eux est soit la couche application ou la couche présentation.
Si les DTO sont uniquement à des fins de présentation, alors la couche de présentation est un bon choix.
S'ils font partie d'une API, que ce soit pour l'entrée ou la sortie, c'est une préoccupation pour la couche application. La couche application est ce qui connecte votre modèle de domaine au monde extérieur.
Comme observation intéressante, il s'ensuit que la couche de présentation doit accéder au modèle de domaine uniquement via la couche d'application . Sinon, nous perdons notre point d'accès unique - nous aurions plusieurs couches appelant le modèle de domaine. La couche application expose tous nos cas d'utilisation. Qu'elles soient invoquées par un appel d'un autre service ou par la couche de présentation, cela ne fait aucune différence.
Sources
Le cœur de ces concepts que j'ai appris de The Red Book par Vaughn Vernon. (Je voudrais en citer un extrait, mais je ne l'ai pas à portée de main.) Les chapitres concernant la couche application et la couche présentation sont pertinents.
Principalement, mes conclusions viennent d'être stricte avec les concepts présentés par Eric Evans et Vaughn Vernon, et de prioriser la liberté dans le modèle de domaine, car c'est piloté par le domaine Conception:
- Le modèle de domaine devrait être facile à changer. Cela signifie ne pas exposer les objets de domaine en externe, car avoir des dépendants externes les rendrait difficiles à changer (sans casser les choses).
- La couche application est le point d'accès externe. C'est ce qui définit les cas d'utilisation sur le modèle de domaine. Cela signifie que ne pas fonctionner sur le modèle de domaine d'ailleurs. La couche présentation ne peut passer que par la couche application. Personne n'aime avoir à gérer de nombreux points d'accès différents!