domain-driven-design - significado - domain driven design example

Objetos Value vs Entity(Diseño Dirigido por Dominio) (7)

3 distinción entre Entities y Value Objects

Identificador vs igualdad estructural: las entidades tienen identificador, las entidades son las mismas si tienen el mismo identificador. Los objetos de valor que están 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 vs inmutabilidad: los objetos de valor son estructuras de datos inmutables mientras que las entidades cambian durante su tiempo de vida.
Vida útil: los objetos de valor deben pertenecer a entidades

Acabo de comenzar a leer DDD. No puedo comprender completamente el concepto de objetos Entidad vs Valor ... ¿Puede alguien explicar los problemas (mantenimiento, rendimiento, etc.) que un sistema podría enfrentar cuando un objeto Valor está diseñado como un objeto Entidad? Ejemplo sería genial ...

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 eso 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 puede definirse como inmutable.

Una forma más simple 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.

La dirección puede ser una entidad o un objeto de valor que depende del proceso de ocupado. 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 asuntos de identidad de la aplicación de mensajería para el objeto de dirección

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

Toma este caso: estás viviendo en tu casa con otras personas. Si usáramos Entity for Address, argumentaríamos que habría una dirección única a la que se vincularían todos los objetos Person. Si una persona se muda, quiere actualizar su dirección. Si actualiza 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? Debo decir que todavía 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 Address como columnas en la tabla Person o crearía una tabla Address 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.

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 superan con creces a las ''escrituras'' y dado que muchas solicitudes web están afectando al ''conjunto activo'' de objetos, no quiero seguir cargando Clientes una y otra vez. Así que me dirigí a un camino inmutable para el objeto del cliente: cargarlo, almacenarlo en caché y servir el mismo para el 99% de las solicitudes (multiproceso) que desea 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 que si muchos subprocesos ven el mismo objeto de cliente y es mutable, cuando un subproceso comienza a cambiar, el caos se produce en los demás.

Mis problemas ahora son: 1) es esto 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 sí mismo, depende de los tipos de entidad.
El objeto Value Type pertenece a un Objeto de tipo de entidad.
La vida útil de una instancia de tipo de valor está limitada por la duración 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

Reducido 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 puede estar compuesta por un Nombre de cliente (objeto de valor), una Lista <Orden> Historial de Pedidos (Lista de entidades) y tal vez una Dirección por defecto (generalmente un objeto de valor). La Entidad Cliente tendría una ID, y cada orden 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 importe.

Los objetos de valor típicamente se pueden representar como objetos inmutables; cambiar una propiedad de un objeto de valor esencialmente destruye el objeto viejo y crea uno nuevo, porque no le preocupa tanto la identidad como el contenido. Correctamente, el método de instancia Equals en Name devolverá "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 es típicamente mutable. La identidad sigue siendo la misma (al menos una vez que el objeto ha sido persistido).

Probablemente crees objetos de valor sin darte cuenta; cada vez que representa un aspecto de una Entidad creando una clase de grano fino, tiene un objeto de valor. Por ejemplo, una clase IPAddress, que tiene algunas restricciones en los valores válidos pero se compone de tipos de datos más simples, sería un objeto de valor. Una 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 un conjunto 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 varios campos en su base de datos cuando piense en la persistencia, pero a su modelo de objetos no le importa.