domain driven design - query - Objetos de valor en CQRS: dónde usar

microservices cqrs event sourcing

Question

Digamos que tenemos una arquitectura inspirada en CQRS, con componentes tales como Comandos, Modelo de dominio, Eventos de dominio, Leer modelos DTO.
Por supuesto, podemos usar Value Objects en nuestro Modelo de Dominio. Mi pregunta es, ¿deberían usarse también en:

1. Comandos
2. Eventos
3. DTOs

No he visto ejemplos donde se usen objetos de valor (VO) en los componentes mencionados anteriormente. En cambio, se usan tipos primitivos. Tal vez solo sean los ejemplos simplistas. Después de todo, mi comprensión del uso de VO en DDD es que actúan como un pegamento para toda la aplicación.

Mi motivación:

Comandos
Digamos que el usuario envía un formulario que contiene campos de dirección. Tenemos Address Value Object para representar este concepto. Al construir un comando en el cliente, debemos validar la entrada del usuario de todos modos, y cuando está bien formado, podemos crear el objeto de Dirección allí mismo e inicializar el Comando con él. No veo la necesidad de delegar la creación del objeto Address en el controlador de comandos.

Eventos de dominio.
El Modelo de dominio ya funciona en términos de Objetos de valor, por lo que al publicar eventos con VO en lugar de convertirlos a tipos primitivos, podemos evitar algunos códigos de mapeo. Estoy bastante seguro de que está bien usar VO en este caso.

DTOs.
Si nuestros DTO del lado de la consulta pueden contener objetos de valor, esto permite un poco más de flexibilidad. Por ejemplo, si tenemos un objeto Money, podemos elegir si mostrarlo en EUR o USD, sin necesidad de cambiar el Modelo de lectura.

Answer 1

De manera similar a otras respuestas, en SOA esto rompería la encapsulación del servicio ya que ahora el dominio se está filtrando.

Answer 2

Ok, he cambiado de opinión. He intentado tratar con los VO un montón últimamente y después de ver esto http://www.infoq.com/presentations/Value-Objects-Dan-Bergh-Johnsson me aclararon un par de cosas.

Los comandos y eventos son mensajes (y no objetos, los objetos son datos + comportamiento), en algunos aspectos muy parecidos a los DTO, comunican datos sobre un evento y ellos mismos no encapsulan ningún comportamiento.

Los objetos de valor no son como DTO en absoluto. Son una representación de dominio y, en términos generales, son muy ricas en comportamiento, como en todas las demás representaciones de dominio.

Los Comandos y Eventos comunican información dentro y fuera del dominio respectivamente, pero ellos mismos no encapsulan ningún comportamiento. Desde esa perspectiva, parece incorrecto y posiblemente una violación de los límites del contexto pasar VO dentro de ellos.

Parafraseando a Oren (aunque se estaba refiriendo a nHibernate y WCF) "No envíe su dominio a través del cable". http://ayende.com/Blog/archive/2009/05/14/the-stripper-pattern.aspx

Si desea comunicar un objeto de valor, sugiero que pase los atributos necesarios necesarios para reconstruir el VO dentro de ellos.

Texto original (para la posteridad):

Si está preguntando si Value Objects puede ser pasado por el modelo de dominio a eventos o pasado por comandos, realmente no veo un gran problema con el primero, aunque este último puede violar algunas de las reglas de la raíz de agregado siendo el "propietario" de valores.

Dicho esto, un objeto de valor representa conceptos como, por ejemplo, un color. No tienes verde, eres verde o no. Parece que no hay nada intrínsecamente incorrecto con un comando que te dice que eres verde al pasar esto.

Leer el capítulo de DDD en el patrón Agregado de la raíz explica Entidades y Objetos de valor bastante bien y vale la pena leerlo varias veces.

Answer 3

Según Clean Code, sus DTO son estructuras de datos (solo para agregar otro término), mientras que los objetos de valor son objetos. La diferencia de que los objetos pueden tener comportamiento. En general, mezclar estructuras de datos con objetos es una muy mala idea, porque será difícil mantener el híbrido que obtienes.

No me siento bien al poner objetos de valor a los DTO desde una perspectiva de arquitectura también. Los objetos de valor están dentro del modelo de dominio mientras que los DTO que mencionó están definiendo la interfaz del modelo. Usualmente construimos una interfaz para desacoplar el mundo exterior del interior de algo. Entonces, en el caso actual, agregamos DTO para desacoplar el mundo exterior de los objetos de valor (y otras cosas relacionadas con el modelo). Después de eso, agregar objetos de valor a la interfaz es una locura.

Entonces no has encontrado esta solución porque es un antipatrón.

Answer 4

Yo digo que es una mala idea.

Hay una razón por la que no hacemos lo mismo con las entidades: para evitar acoplar otras partes del sistema al dominio (en los lugares incorrectos). Lo mismo es cierto para los objetos de valor, la única diferencia entre los objetos de valor y las entidades es la duración y la propiedad: estas diferencias no afectan la forma en que deberíamos y no deberíamos asociarlas.

Imagine que hace que un evento contenga un VO. Un cambio en su dominio requiere que cambie ese VO. Ahora te has encerrado en una esquina donde tu evento también se ve obligado a cambiar, lo mismo para cualquier comando o DTO del que sea parte.

Esto debe ser evitado.

Use DTO''s y / o primitivos. Localícelos (AutoMapper lo convierte en un acuerdo de 1 línea).