Value objetos en CQRS - dónde usar

Question

Digamos que tenemos una arquitectura inspirada en CQRS, con componentes como comandos, modelo de dominio, eventos de dominio, lectura de DTOS modelo.
Por supuesto, podemos usar objetos de valor en nuestro modelo de dominio. Mi pregunta es, si también se usan en:

1. Comandos
2. Eventos
3. DTOS

No he visto ningún ejemplo en los que se usen los objetos de valor (VO) en los componentes mencionados anteriormente. En cambio, se utilizan tipos primitivos. Tal vez son solo los ejemplos simplistas. Después de todo, mi comprensión del uso de VOS 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 objeto de valor de dirección para representar este concepto. Al construir el 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 de dirección al 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 en tipos primitivos, podemos evitar algún código de mapeo. Estoy bastante seguro de que está bien usar VOS en este caso.

DTOS.
Si nuestro DTOS del lado de la consulta puede contener objetos de valor, esto permite una mayor flexibilidad. Por ejemplo, si tenemos objeto de dinero, podemos elegir si mostrarlo en EUR o USD, no es necesario cambiar el modelo de lectura.

Answer 1

Ok, he cambiado de opinión. He estado tratando de lidiar con Vos un montón últimamente y después de ver esto http://www.infoq.com/presentations/value-objects-dan-bergh-Jambhnsson Aclaró un par de cosas para mí.

Los comandos y el evento 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 general, son ricos en un comportamiento como 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 un contexto de violación límites para pasar Vos dentro de ellos.

Parafraseando a Oren (aunque se refería 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 pasar los atributos necesarios necesarios para volver a construir el VO dentro de ellos.

Texto original (para la posteridad):

Si está preguntando si los objetos de valor pueden ser transmitidos por el modelo de dominio a los eventos o pasar por comandos, realmente no veo un gran problema con el primero, aunque el segundo puede violar algunas de las reglas de la raíz agregada que son la "propietario" de valores.

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

Leer el capítulo de DDD sobre el patrón de raíz agregada explica las entidades y los objetos de valor bastante bien y vale la pena leer algunas veces.

Answer 2

Digo que es una mala idea.

Hay una razón por la que no hacemos lo mismo con las entidades: evitar acoplar otras partes del sistema al dominio (en los lugares equivocados). Lo mismo es cierto para los objetos de valor, la única diferencia entre los objetos de valor y las entidades es la vida útil y la propiedad: estas diferencias no afectan cómo debemos y no debemos acoplarlos.

Imagina que haces un evento contener un VO. Un cambio en su dominio requiere que cambie ese VO. Ahora te has encajonado en una esquina donde también está tu evento forzado Para cambiar, lo mismo en cualquier comando o DTO de los que es parte.

Esto debe evitarse.

Use DTO y/o primitivos. Mapealos (Automapper lo convierte en un acuerdo de 1 línea).

Answer 3

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

Answer 4

De acuerdo a Código limpio 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. Mezclar estructuras de datos con objetos es generalmente una muy mala idea, porque será difícil mantener el híbrido que obtenga.

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. Por lo general, construimos una interfaz para desacoplar el mundo exterior desde el 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.

Así que aún no has cumplido con esta solución porque es un antipatrón.