Objetos de valor vs entidad (diseño controlado por dominio)

Acabo de empezar a leer DDD. No puedo comprender completamente el concepto de objetos Entidad vs Valor. ¿Puede alguien explicar los problemas (mantenibilidad, rendimiento, etc.) que un sistema podría enfrentar cuando un objeto Valor se diseña como un objeto Entidad? Un ejemplo sería genial ...

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 Cliente puede estar compuesta por un Nombre de cliente (objeto de valor), Lista <Orden> Historial de pedidos (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 de todos modos, la identidad de una dirección probablemente no importa.

Los objetos de valor se pueden representar normalmente como objetos inmutables; cambiar una propiedad de un objeto de valor esencialmente destruye el objeto antiguo y crea uno nuevo, porque no le preocupa tanto la identidad como el contenido. De forma adecuada, el método de instancia Equals en Name 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 Cliente suele ser mutable. La identidad sigue siendo la misma (al menos una vez que se ha conservado el objeto).

Probablemente crea objetos de valor sin darse cuenta; siempre que esté representando algún aspecto de una entidad mediante la creación de una clase detallada, tendrá un objeto de valor. Por ejemplo, una clase IPAddress, que tiene algunas restricciones sobre valores válidos pero está compuesta por tipos de datos más simples, sería un objeto de valor. Un EmailAddress podría ser una cadena o podría ser 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 objetos. Pero el caso más simple es una combinación de algunos atributos que tienen sentido juntos. Probablemente 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 cuando piense en la persistencia, pero a su modelo de objetos no le importa.

Cualquier objeto que esté definido colectivamente por todos sus atributos es un objeto de valor. Si cambia alguno de los atributos, tiene una nueva instancia de un objeto de valor. Por eso 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 como 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.

Tipos de valor:

• Los tipos de valor no existen por sí solos, 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 la entidad propietaria.
• Tres tipos de valores: básico (tipos de datos primitivos), compuesto (dirección) y colección (mapa, lista, matrices)

Entidades:

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

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ían en todos los objetos vinculados ( una Persona, por ejemplo).

Tome este caso: vive en su casa con otras personas. Si usáramos Entidad para Dirección, yo diría que habría una Dirección única a la que se vinculan todos los objetos Persona. Si una persona se muda, desea actualizar su dirección. Si actualizara las propiedades de la entidad de dirección, todas las personas tendrían 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.

¿Suena bien esto? Debo decir que también estaba / 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 Dirección como columnas en la tabla Persona o crearía una tabla Dirección separada que también tendría un identificador único? En el último caso, las personas que viven en la misma casa tendrían cada una una instancia diferente de un objeto Dirección, pero esos objetos serían los mismos excepto por su propiedad ID.

La dirección puede ser una entidad o un objeto de valor que depende del proceso de negocio. El objeto de dirección puede ser una entidad en la aplicación de servicio de mensajería, pero la dirección puede ser un objeto de valor en alguna otra aplicación. en cuestiones de identidad de aplicaciones de mensajería 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 necesita. Eso suena tonto, pero las 'lecturas' de los datos de los clientes superan con creces las 'escrituras' y, dado que muchas solicitudes web están afectando el 'conjunto activo' de objetos, no quiero seguir cargando Clientes una y otra vez. Así que me dirigí por un camino inmutable para el objeto Cliente: cárguelo, almacénelo en caché y entregue el mismo al 99% de las solicitudes (de subprocesos múltiples) que desean ver al Cliente. Luego, cuando un cliente cambie algo, obtenga un 'editor' para crear un nuevo Cliente e invalidar el anterior.

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

Mis problemas ahora son, 1) esto es razonable, y 2) cuál es la mejor manera de hacer esto sin duplicar mucho código sobre las propiedades.

3 distinción entre EntitiesyValue Objects

• Identificador vs 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 dos objetos de valor iguales cuando todos los campos son iguales. Los objetos de valor no pueden tener identificador.

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

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

En una oración muy simple puedo decir, tenemos tres tipos de igualdad:

• Igualdad de identificador : una clase tiene un archivo id y dos objetos se comparan con su valor de campo id.
• Igualdad de referencia : si una referencia a dos objetos tiene la misma dirección en la memoria.
• Igualdad estructural : dos objetos son iguales si todos sus miembros coinciden.

La igualdad de identificador se refiere solo a la entidad y la igualdad estructural se refiere solo al objeto de valor. De hecho, los objetos de valor no tienen id y podemos usarlos indistintamente. también los objetos de valor deben ser inmutables y las entidades pueden ser mutables y los objetos de valor no tendrán ninguna tabla en la base de datos.