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 ...
Respuestas:
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.
int[1]puede ser un valor mutable no compartido, un valor inmutable que se puede compartir (si ninguna de las cosas que tienen referencias alguna vez escribirá en él), o una entidad (si existen dos o más referencias, y una de ellas puede usarse para escribir valores que se pueden leer con el otro). Desafortunadamente, no conozco ningún soporte de lenguaje en Java o .NET para evitar que los objetos de clase que encapsulan valores mutables se conviertan accidentalmente en entidades.
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:
Entidades:
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:
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.