modèle de domaine anémique vs modèle de domaine

Question

Être de nouveau confus après avoir pris connaissance de cet anti-modèle et des nombreuses préoccupations à ce sujet sur SO.

Si j'ai un modèle de domaine et que je capture les données à conserver dans un objet de transfert de données, mon modèle de domaine est-il un wrapper autour des données? Dans ce cas, j'utiliserais un modèle de domaine anémique. Mais si j’ajoute assez de logique de domaine sur ce wrapper, à quel moment devient-il un véritable modèle de domaine?

J'ai l'impression que la capture de ce qui doit être conservé dans un modèle de domaine est une violation des bonnes pratiques et crée l'anti-modèle du modèle de domaine anémique. Pourtant, si vous utilisez une base de données relationnelle, vous ne pouvez éviter de sélectionner la partie qui crée l’état de l’objet et de la sauvegarder.

Comme je suis assez confus au sujet des concepts, je ne suis pas sûr que ce que j’écris ait un sens. N'hésitez pas à demander des éclaircissements.

Answer 1

Il devient un modèle de domaine "réel" lorsqu'il contient tout (ou la plupart) du comportement qui constitue le domaine professionnel (remarque sur laquelle je souligne logique d’entreprise , pas d’interface utilisateur ou d’autres problèmes orthogonaux).

Si vous utilisez la langue omniprésente et que vous obtenez un feedback constant de la part de vos experts de domaine , vous saurez que vous êtes sur la bonne voie (les experts doivent acquiescer lorsqu'ils voient votre modèle de domaine). Si vous ne faites pas ces choses, vous ne faites pas de DDD ( Eric Evans en parle ).

À propos des DTO: ne les ignorez pas. Du point de vue de la mise en œuvre, vous en aurez besoin pour transporter les données entre les couches / niveaux. La manière dont vous combinez les DTO et les vrais objets de domaine dépend vraiment de la technologie que vous utilisez.

Comme mentionné dans une réponse précédente, peut-être que votre intérêt pour les données et la persistance vous distrait de la vraie modélisation de domaine ...

Answer 2

Deux points d’intérêt me viennent à l’esprit:

• Les objets de transfert de données (DTO) sont différents des objets de domaine. Ils servent différents objectifs dans différents endroits d'une architecture - ne les confondez pas. Les objets de domaine fournissent une API riche avec une cohésion élevée . Les DTO sont des structures de données passives utilisées dans l'interface externe d'une application, tout comme l'interface utilisateur ViewModels, mais destinées à des systèmes automatisés plutôt qu'à des utilisateurs.
• Efforcez-vous après avoir sélectionné un ORM permettant d'utiliser Ignorance de la persistance . Cela signifie que vous pouvez définir votre modèle de domaine de manière illimitée et simplement faire en sorte que l'ORM mappe les objets sur une base de données relationnelle.

Answer 3

  

Mais si j'ajoute assez de logique de domaine sur ce wrapper, à quel moment devient-il un véritable modèle de domaine?

Il est possible d’atteindre le modèle de domaine en ajoutant des éléments au hasard, mais certainement pas de conception orientée domaine. (Je sais que cela n’est pas vraiment utile. J’ai tendance à penser que je suis très centré sur les données et que, dans certains cas, cela demande un réel effort de se tirer de ce point de vue.)