Valeur Objets dans CQRS - où l'utilisation

Question

Disons que nous avons architecture CQRS inspirés, avec des composants tels que les commandes, modèle de domaine, des événements de domaine, Lire modèle DTO.
Bien sûr, nous pouvons utiliser les objets Valeur dans notre modèle domaine. Ma question est, devrait-ils être utilisés aussi dans:

1. Commandes
2. Événements
3. DTO

Je n'ai pas vu des exemples où les objets de valeur (VO) sont utilisés dans les composants mentionnés ci-dessus. Au lieu de cela, les types primitifs sont utilisés. Peut-être juste les exemples simplistes. Après tout, ma compréhension de l'utilisation en DDD est VOs qu'ils agissent comme une colle pour toute l'application.

Ma motivation:

Commandes.
Mettons-nous d'utilisateur soumet dire formulaire qui contient des champs d'adresse. Nous avons Adresse Valeur objet pour représenter ce concept. Lors de la construction commande du client, nous devons valider toute façon l'entrée d'utilisateur, et quand il est bien formé, nous pouvons créer un objet d'adresse là et commande d'initialisation avec elle. Je ne vois pas besoin de déléguer la création d'objet d'adresses pour gestionnaire de commandes.

Événements de domaine.
Modèle de domaine fonctionne déjà en termes d'objets valeur, donc en publiant des événements avec au lieu de VOs les convertir à des types primitifs, nous pouvons éviter un code de cartographie. Je suis sûr qu'il va bien à l'utilisation VOs dans ce cas.

DTO.
Si nos DTO côté de requête peut contenir des objets valeur, cela permet une plus grande flexibilité. Par exemple, si nous avons l'objet de l'argent, nous pouvons choisir d'afficher en EUR ou USD, pas besoin de changer de modèle Lire.

Answer 1

Ok j'ai changé d'avis. Je suis en train de traiter VOs un groupe ces derniers temps et après avoir vu cette http: //www.infoq .com / présentations / Value-Objets-Dan-Bergh-Johnsson il a précisé un certain nombre de choses pour moi.

Commandes et événements sont des messages (et les objets non, les objets sont données + comportement), à certains égards, un peu comme DTO, ils communiquent des données sur un événement et ils se résument pas de comportement.

Objets valeur ne sont pas comme DTO du tout. Ils sont une représentation de domaine et ils sont, en général, riche sur le comportement comme toutes les autres représentations de domaine.

Commandes et événements communiquent des informations dans et hors du domaine respectivement, mais ils ne se résument pas de comportement. De ce point de vue il semble erroné et un peut-être une des limites de contexte de violation de passer VOs l'intérieur d'eux.

Pour paraphraser Oren (bien qu'il se référait à NHibernate et WCF) « Ne pas envoyer votre domaine à travers le fil ». http://ayende.com/Blog/archive/2009/05/14/ le stripper-pattern.aspx

Si vous voulez communiquer un objet de valeur, alors je suggère passer les attributs nécessaires nécessaires pour reconstruire la VO au sein de leur place.

Texte original (pour la postérité):

Si vous demandez si des objets La valeur peut être transmis par le modèle de domaine à des événements ou transmise par les commandes, je ne vois pas vraiment un énorme problème avec l'ancien, bien que celui-ci peut violer certaines des règles de l'agrégat racine étant le « propriétaire » des valeurs.

Cela dit un objet de valeur représente des concepts comme par exemple une couleur. Vous ne faites pas Vous vert, vous sont vert ou non. Il semble y avoir rien d'intrinsèquement mauvais avec une commande indiquant que vous êtes vert en passant cela.

La lecture du chapitre de DDD sur le modèle d'agrégat racine explique les entités et la valeur des objets très bien et mérite d'être lu à quelques reprises.

Answer 2

Je dis que c'est une mauvaise idée.

Il y a une raison pour laquelle nous ne faisons pas la même chose avec des entités - pour éviter un couplage d'autres parties du système au domaine (dans les mauvais endroits). La même chose est vraie pour la valeur des objets, la seule différence entre les objets de valeur et les entités est la vie et la propriété -. Ces différences ne touchent pas comment nous devrions et ne devrait pas les deux

Imaginez que vous faites un événement contient une VO. Un changement dans votre domaine vous oblige à changer que VO. Vous vous êtes maintenant mis en boîte dans un coin où votre événement est également forcé au changement, idem pour les commandes ou DTO il est partie.

Il est à éviter.

Utilisation de DTO et / ou primitives. Carte les (AutoMapper en fait une affaire 1 ligne).

Answer 3

Comme dans d'autres réponses, en SOA ce briserait l'encapsulation du service que le domaine est maintenant FUITES.

Answer 4

Selon code propre vos DTO sont des structures de données (juste ajouter un autre terme), tandis que les objets de valeur sont des objets. La différence que les objets peuvent avoir un comportement. Le mélange des structures de données avec des objets est généralement une très mauvaise idée, car il sera difficile de maintenir l'hybride que vous obtenez.

Je ne me sens pas le droit de mettre des objets de valeur à DTO du point de vue de l'architecture aussi bien. Les objets de valeur sont à l'intérieur du modèle de domaine alors que les DTO que vous avez mentionnés définissent l'interface du modèle. Nous construisons habituellement une interface pour découpler le monde extérieur à l'intérieur de quelque chose. Donc, dans le cas présent, nous avons ajouté DTO à découpler le monde extérieur à partir des objets de valeur (et autres modèles choses connexes). Après que l'ajout d'objets de valeur à l'interface est fou.

Vous n'avez pas encore rencontré cette solution car il est un anti-modèle.