Objetos de valor frente a entidad (diseño impulsado por dominio)

Reducida a la distinción esencial, la identidad importa para las entidades, pero no importa para los objetos de valor. Por ejemplo, el nombre de alguien es un objeto de valor. Una entidad de Cliente podría estar compuesta por un Nombre de cliente (objeto de valor), Lista <Order> OrderHistory (Lista de entidades) y tal vez una Dirección predeterminada (generalmente un objeto de valor). La Entidad del cliente tendría una ID, y cada pedido tendría una ID, pero un Nombre no debería; En general, dentro del modelo de objetos, la identidad de una dirección probablemente no importa.

Los objetos de valor normalmente pueden representarse como objetos inmutables; Cambiar una propiedad de un objeto de valor esencialmente destruye el objeto antiguo y crea uno nuevo, porque no le interesa tanto la identidad como el contenido. Apropiadamente, el método de instancia de Igualdad en Nombre devolvería "verdadero" siempre que las propiedades del objeto sean idénticas a las propiedades de otra instancia.

Sin embargo, cambiar algún atributo de una entidad como Cliente no destruye al cliente; una entidad de cliente suele ser mutable. La identidad sigue siendo la misma (al menos una vez que el objeto ha sido persistido).

Probablemente creas objetos de valor sin darte cuenta; En cualquier momento que esté representando algún aspecto de una Entidad al crear una clase de grano fino, tiene un objeto de valor. Por ejemplo, una clase de dirección IP, que tiene algunas restricciones sobre valores válidos pero está compuesta de tipos de datos más simples, sería un objeto de valor. Una dirección de correo electrónico puede ser una cadena o un objeto de valor con su propio conjunto de comportamientos.

Es muy posible que incluso los elementos que tienen una identidad en su base de datos no tengan una identidad en su modelo de objeto. Pero el caso más simple es un compuesto de algunos atributos que tienen sentido juntos. Es probable que no desee tener Customer.FirstName, Customer.LastName, Customer.MiddleInitial y Customer.Title cuando puede componerlos juntos como Customer.Name; probablemente serán múltiples campos en su base de datos para cuando piense en la persistencia, pero a su modelo de objeto no le importa.

Cualquier objeto que se define colectivamente por todos sus atributos es un objeto de valor. Si alguno de los atributos cambia, tiene una nueva instancia de un objeto de valor. Es por esto que los objetos de valor se definen como inmutables.

Si el objeto no está completamente definido por todos sus atributos, entonces hay un subconjunto de atributos que conforman la identidad del objeto. Los atributos restantes pueden cambiar sin redefinir el objeto. Este tipo de objeto no se puede definir en inmutable.

Una forma más sencilla de hacer la distinción es pensar en los objetos de valor como datos estáticos que nunca cambiarán y las entidades como datos que evolucionan en su aplicación.

No sé si lo siguiente es correcto, pero diría que en el caso de un objeto de Dirección, queremos usarlo como un Objeto de Valor en lugar de una Entidad porque los cambios en la entidad se reflejarán en todos los objetos vinculados ( una persona por ejemplo).

Toma este caso: estás viviendo en tu casa con otras personas. Si usaríamos la Entidad para la Dirección, argumentaría que habría una Dirección única a la que se vincularían todos los Objetos Personales. Si una persona se muda, usted quiere actualizar su dirección. Si actualizas las propiedades de la entidad de dirección, todas las personas tendrán una dirección diferente. En el caso de un Objeto de valor, no podríamos editar la Dirección (ya que es inmutable) y nos veríamos obligados a proporcionar una nueva Dirección para esa Persona.

¿Esto suena bien? Debo decir que yo estaba/todavía estoy confundido acerca de esta diferencia, después de leer el libro de DDD.

Yendo un paso más allá, ¿cómo se modelaría esto en la base de datos? ¿Tendría todas las propiedades del objeto de Dirección como columnas en la tabla de Persona o crearía una tabla de Dirección separada que también tendría un identificador único? En este último caso, las personas que viven en la misma casa tendrían cada una una instancia diferente de un objeto de Dirección, pero esos objetos serían los mismos excepto por su propiedad de ID.

la dirección puede ser una entidad o un objeto de valor que depende del proceso de busiess. el objeto de dirección puede ser una entidad en la aplicación de servicio de mensajería, pero la dirección puede ser objeto de valor en alguna otra aplicación. En la aplicación de mensajería, la identidad importa para el objeto de dirección.

Pregunté sobre esto en otro hilo y creo que todavía estoy confundido. Puedo confundir las consideraciones de rendimiento con el modelado de datos. En nuestra aplicación de catalogación, un cliente no cambia hasta que lo necesite. Eso suena tonto, pero las "lecturas" de los datos de los clientes son mucho más numerosas que las "escrituras" y, dado que muchas de las solicitudes web están afectando al "conjunto activo" de objetos, no quiero seguir cargando Clientes una y otra vez. Así que me dirigí por un camino inmutable para el objeto del Cliente: cárguelo, guárdelo y sirva el mismo al 99% de las solicitudes (de múltiples hilos) que quieren ver al Cliente. Luego, cuando un cliente cambia algo, obtenga un 'editor' para crear un nuevo Cliente e invalidar el anterior.

Mi preocupación es si muchos subprocesos ven el mismo objeto de cliente y es mutable, entonces, cuando un subproceso comienza a cambiarlo, se produce un caos en los demás.

Mis problemas ahora son: 1) es razonable y 2) la mejor manera de hacerlo sin duplicar mucho código sobre las propiedades.

Tipos de valor:

• Los tipos de valor no existen por su cuenta, depende de los tipos de entidad.
• El objeto de tipo de valor pertenece a un objeto de tipo de entidad.
• La vida útil de una instancia de tipo de valor está limitada por la vida útil de la instancia de entidad propietaria.
• Tres tipos de valores: Básico (tipos de datos primitivos), Compuesto (Dirección) y Colección (Mapa, Lista, Arreglos)

Entidades:

• Los tipos de entidad pueden existir por su cuenta (Identidad)
• Una entidad tiene su propio ciclo de vida. Puede existir independientemente de cualquier otra entidad.
• Por ejemplo: Persona, Organización, Colegio, Móvil, Hogar, etc. Cada objeto tiene su propia identidad.

3 distinción entre Entities y Value Objects

• Identificador frente a igualdad estructural: las entidades tienen identificador, las entidades son iguales si tienen el mismo identificador. Los objetos de valor más allá de la mano tienen igualdad estructural, consideramos que dos objetos de valor son iguales cuando todos los campos son iguales. Los objetos de valor no pueden tener identificador.

• Mutabilidad frente a inmutabilidad: los objetos de valor son estructuras de datos inmutables, mientras que las entidades cambian durante su vida útil.

• Vida útil: los objetos de valor deben pertenecer a entidades