Pourquoi dois-je isoler mon domaine entités de ma couche de présentation?

Question

Une partie de domain-driven design que il ne semble pas y avoir beaucoup de détails sur comment et pourquoi vous devriez vous isoler de votre modèle de domaine à partir de votre interface. J'essaie de convaincre mes collègues que c'est une bonne pratique, mais je ne semble pas faire beaucoup de progrès...

Ils utilisent domaine des entités où ils s'il vous plaît dans la présentation et l'interface des couches. Quand j'font valoir qu'ils devraient être à l'aide de modèles d'écrans ou de l'Otd pour isoler la couche Domaine de la couche d'interface, ils ont contre qu'ils ne voient pas la valeur de l'entreprise à faire quelque chose comme ça, parce que maintenant vous avez un objet d'INTERFACE utilisateur à maintenir ainsi que le domaine d'origine de l'objet.

Donc, je suis à la recherche pour certaines des raisons que je peux utiliser pour. Plus précisément:

1. Pourquoi devrions-nous ne pas utiliser des objets du domaine dans notre couche de présentation?
   (si la réponse est évidente, 'découplage', alors s'il vous plaît expliquer pourquoi c'est important dans ce contexte)
2. Doit-on utiliser d'autres objets ou constructions à isoler nos objets du domaine de l'interface?

Answer 1

Tout simplement, la raison est l'un de la mise en œuvre et de la dérive. Oui, la couche de présentation doit savoir à propos de votre business objects pour être en mesure de les représenter correctement. Oui, d'abord, il semble comme il y a beaucoup de chevauchement entre la mise en œuvre des deux types d'objets. Le problème est, comme le temps passe, les choses se ajoutés sur les deux côtés. Les changements de la présentation, et les besoins de la couche de présentation évoluer pour inclure des choses qui sont complètement indépendants l'un de vos affaires (couche de couleur, par exemple). Pendant ce temps, votre domaine d'objets changent au fil du temps, et si vous n'avez pas de découplage à partir de votre interface, vous courez le risque de foutre en l'air votre interface de la couche en faisant en apparence bénigne modifications à votre entreprise les objets.

Personnellement, je crois que la meilleure façon d'aborder les choses est par le biais de la stricte à l'interface de paradigme; c'est, votre entreprise de calque d'objet expose une interface qui est la seule façon dont il peut être communiquées avec; pas de détails de mise en œuvre (c'est à dire des objets du domaine) à propos de l'interface sont exposés. Oui, cela signifie que vous avez à mettre en œuvre votre domaine d'objets en deux endroits; votre couche d'interface et dans votre BO couche. Mais cette remise à plat, alors qu'il peut sembler être une charge de travail supplémentaire, à imposer l'application du découplage, qui permettra d'économiser des TONNES de travail à un certain moment dans l'avenir.

Answer 2

J'ai lutté avec moi-même. Il y a des cas où un DTO est logique de l'utiliser dans presentaton. Disons que je veux afficher une liste déroulante de Sociétés dans mon système et j'ai besoin de leur id pour lier la valeur de.

Eh bien au lieu de chargement d'une CompanyObject qui pourrait avoir des références à des abonnements ou qui sait quoi d'autre, je pourrais envoyer un DTO avec le nom et l'id. C'est une bonne utilisation de mon humble avis.

Maintenant prenons un autre exemple. J'ai un objet qui représente une Estimation, cette estimation peut être faite de travail, de l'équipement, etc, il pourrait avoir beaucoup de calculs qui sont définis par l'utilisateur qui prend tous ces éléments et de les résumer (Chaque estimation peut être différent avec différents types de calculs). Pourquoi devrais-je avoir pour modèle de cet objet deux fois? Pourquoi ne puis-je pas simplement mes UI énumérer sur les calculs et de les afficher?

En général, je n'utilisez pas de DTO pour isoler mon domaine de couche à partir de mon INTERFACE. Je ne les utiliser pour isoler mon domaine calque à partir d'une limite de ce qui est hors de mon contrôle. L'idée que quelqu'un pourrait mettre les informations de navigation de leur objet métier est ridicule, de ne pas contaminer votre business object.

L'idée que quelqu'un aurait mis la validation de leur objet métier? Et bien moi je dis que c'est une bonne chose. Votre INTERFACE utilisateur ne doit pas avoir l'entière responsabilité de valider votre business objects. Votre couche de gestion DOIT faire sa propre validation.

Pourquoi voudriez-vous mettre de l'INTERFACE utilisateur de génération de code dans un busienss objet? Dans mon cas, j'ai séparé les objets qui génère le code de l'INTERFACE utilisateur seperatley à partir de l'INTERFACE utilisateur. J'ai sperate objets qui rendent mon entreprise objets en Xml, l'idée que vous avez séparé vos couches pour éviter ce type de contamination est très étrange pour moi parce que pourquoi voudriez-vous même mettre HTML de génération de code dans un objet métier...

Modifier Comme je pense un peu plus, il ya des cas où les informations concernant l'INTERFACE utilisateur peut appartenir à la couche domaine. Et peut-cloud ce que vous appelez une couche domaine, mais j'ai travaillé sur une application multi-locataires, qui étaient très différents de comportement à la fois ergonomie de l'INTERFACE utilisateur fonctionnelle et flux de travail. En fonction de divers facteurs. Dans ce cas, nous avons eu un modèle de domaine que représentaient les locataires et leur configuration. Leur configuration est arrivé à inclure des informations concernant l'INTERFACE utilisateur (l'Étiquette générique de champs par exemple).

Si j'avais à la conception de mes objets pour les rendre permanent, dois-je également avoir à dupliquer les objets? Gardez à l'esprit si vous voulez ajouter un nouveau champ, vous avez maintenant deux places pour l'ajouter. Peut-être cela soulève une autre question si votre aide DDD, sont toutes les entités persistantes des objets du domaine? Je sais que dans mon exemple, ils ont été.

Answer 3

Je suis en désaccord.

Je pense que la meilleure façon de le faire est de commencer avec des objets du domaine dans la couche de présentation JUSQU'à ce qu'IL est judicieux DE le FAIRE AUTREMENT.

Contrairement à la croyance populaire, les "Objets du Domaine" et "Objets de Valeur" peuvent coexister dans la couche de présentation. Et c'est la meilleure façon de le faire, vous obtenez les avantages des deux mondes, la réduction de la duplication (et de code réutilisable) avec les objets du domaine; et la confection de vêtements et conceptuel de la simplification de l'utilisation de la valeur des objets sur demande.

À l'aide de OpenSessionInView simplifie ce trop. Le temps que vous avez à penser, c'est quand vous avez besoin de ré-attacher un objet de domaine à un nouveau contexte de persistance, et un LazyInitializationException feront très clairement si vous arrive d'oublier.

Answer 4

Vous le faites pour la même raison, vous gardez SQL de votre ASP/JSP pages.

Si vous en garder qu'un objet de domaine, pour une utilisation dans la présentation ET la couche domaine, alors qu'un objet devient monolithique. Il commence à inclure l'INTERFACE utilisateur d'un code de validation, l'INTERFACE utilisateur de code de navigation, l'INTERFACE et de la génération de code. Ensuite, vous ajoutez tous les de la couche de méthodes sur le dessus de cela. Maintenant, votre couche de gestion de l'INTERFACE et sont tous mélangés, et ils sont tous à déconner dans le domaine de l'entité de la couche.

Vous souhaitez réutiliser cette chouette UI widget dans une autre application? Eh bien, Vous devez créer une base de données avec ce nom, ces deux schémas, et ces 18 tables. Vous devez également configurer Hibernate et Spring ( ou de vos cadres au choix ) pour la validation. Oh, vous devez également inclure ces 85 autres non liés à des classes parce qu'ils sont référencés dans la couche de gestion, qui se trouve être dans le même fichier.

Answer 5

C'est à propos de dépendances pour la plupart. Le noyau de la structure fonctionnelle de l'entreprise a ses propres exigences fonctionnelles, et l'INTERFACE utilisateur devrait permettre aux gens de modifier et de visualiser le cœur; mais le cœur lui-même ne devrait pas être nécessaire d'adapter l'INTERFACE utilisateur. (Si elle doit arriver, c'est généralement une indication de la base n'est pas bien conçu.)

Mon système de comptabilité a une structure et un contenu (et les données) qui sont censés modéliser le fonctionnement de mon entreprise. Cette structure est réel et existe indépendamment de ce que la comptabilité logiciel que j'utilise. (Inévitablement un logiciel donné paquet contient la structure et du contenu pour son propre bien, mais une partie du défi est de minimiser ces coûts.)

Fondamentalement, une personne a un travail à faire. Le DDD doit correspondre au flux et le contenu du travail. DDD est de rendre explicite de tous les travaux qui doivent être effectués ad complètement et de façon la plus autonome possible. Ensuite, l'INTERFACE utilisateur, espérons facilite la tâche à accomplir de façon transparente que possible, de la manière la plus productive possible.

Les Interfaces sont sur les entrées et les points de vue pour l'correctement modélisés et invariant noyau fonctionnel.