Objeto de valor único vs entidad


8

Al intentar convertir algunas entidades en objetos de valor, estoy atrapado en un caso en el que lo que parece un objeto de valor debe ser único dentro de un agregado.

Supongamos que tenemos una entidad Movie que forma la raíz de un agregado. Esta entidad de película está relacionada con algún conjunto de objetos AdvertisingEvent con la función de mostrar un anuncio en una determinada marca de tiempo.

El EventEvent contiene un enlace a un Banner que se debe mostrar, las coordenadas y algunos filtros de efectos.

Dado que AdvertisingEvent es solo una colección de parámetros de configuración, no estoy seguro de si debería preocuparme por su identidad y tratarla como un objeto de gran valor. Sin embargo, me importa que dentro de una película debe haber solo un evento de anuncio en una determinada marca de tiempo, probablemente incluso alrededor de las marcas de tiempo.

Me resulta difícil dividir mis dudas en múltiples preguntas independientes, así que ahí van:

  1. ¿Una colección de parámetros de configuración suena como un objeto de valor?
  2. ¿Estoy mezclando el concepto de unicidad de AdvertisingEvent dentro de Movie y la regla de integridad transaccional?
  3. ¿ Alguna de las opciones en el punto (2) implica que AdvertisementEvent debe ser miembro del agregado realizado por Movie ?
  4. ¿Es mi objeto AdvertisingEvent una entidad, un objeto de valor o un objeto de evento? (Usé el sufijo Evento en el nombre para resaltar mi confusión)
  5. ¿Son objetos de gran valor como este un olor de diseño?

Supongo que no estoy tratando con un Evento en el sentido de DDD porque no es algo que simplemente sucede . El verdadero evento DDD debería ser algo más como AdvertisementEventReached

Respuestas:


9

La distinción entre el objeto Entidad y el Valor debe basarse en la pregunta: si tengo dos objetos con el mismo contenido (dos Eventos de Publicidad vinculados al mismo Banner con los mismos parámetros), ¿debería tratarlos de manera diferente o uno puede ser reemplazado por el otro? sin afectar cómo funciona el software?

En este caso, diría que puede reemplazar un AdvertisingEvent por otro con los mismos valores sin afectar el funcionamiento del software. Esto los convierte en objetos de valor (el valor contenido es lo que cuenta, no la identidad del objeto en sí).

En cuanto al tamaño de un objeto Value: siempre que contenga un conjunto coherente de parámetros para una sola responsabilidad, no hay límite en cuanto al tamaño que puede tener un objeto Value. En la implementación, puede ser bueno prestar especial atención a los objetos de gran valor para garantizar que no se copien innecesariamente y en exceso, pero de lo contrario no es un problema.

En cuanto a las restricciones en el número de eventos de publicidad que tiene dentro de una película , esta es una restricción en la relación entre una película y su colección de eventos de publicidad , no en una de esas clases individualmente. Como tal, el lugar más lógico para imponer la restricción es en el punto donde la colección se mantiene en Movie (por lo tanto, en el método en el que intenta agregar un EventEvent ).


¡Muchas gracias! A pesar de haber leído tantas veces acerca de hacer esa pregunta para diferenciar a las Entidades de los Objetos de valor, esta vez finalmente "ha hecho clic". Creo que necesitaba un problema en mi vida real para aprender esa lección. Me encanta mi problema porque expuso un objeto de evento (que no es un evento de dominio) y lo que parece ser unicidad (que es invariante). Supongo que en mi pregunta debería haber dicho "invariante" en lugar de "regla de integridad transaccional".
SystematicFrank

Interesante ... como efecto secundario de comprender mejor esta diferencia, ahora puedo ver claramente la importancia de los objetos de valor sin estado / inmutables para mejorar la estabilidad de mis programas. Supongo que estaba pensando demasiado en los detalles de implementación de la GUI ... la mutación fácil es agradable en la capa de aplicación, pero en la capa de dominio ¡quiero que el evento de publicidad sea inmutable!
SystematicFrank
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.