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 ...Objetos Value vs Entity (Diseño Dirigido por Dominio)
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 Cliente puede estar compuesta de 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 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 generalmente 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.
¿Dónde encajan los objetos mutables no compartidos? Si en todo el universo solo existe una referencia a un objeto, la identidad del objeto será irrelevante, incluso si es mutable. Como yo lo veo, un elemento es una entidad, si existe una referencia que podría usarse, observe un aspecto del estado que podría cambiar * sin que se haya utilizado esa referencia para cambiarlo *. Si una cosa no se adhiere al mundo exterior y es inmutable o solo existe una referencia a ella en cualquier parte del universo, entonces el escenario anterior no puede ocurrir y es un valor. – supercat
Algo así como un 'int [1]' puede ser un valor no compartido mutable, un valor inmutable compartible (si ninguna de las cosas que mantienen referencias volverá a escribir en él), o una entidad (si existen dos o más referencias, y uno de ellos puede usarse para escribir valores que pueden leerse utilizando el otro). Desafortunadamente, no conozco ningún soporte de idioma en Java o .NET para evitar que los objetos de clase que encapsulan valores mutables se conviertan accidentalmente en entidades. – supercat
@supercat, Si se refiere a ningún apoyo directo sencilla, yo estaría de acuerdo, pero hacer esto a mi eliminando el acceso del público a los constructores, utilizando sólo las fábricas estáticos para crear nuevas instancias, y restringir el acceso a todo el estado a través de propiedades de solo lectura (No definidores) –
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.
¿Esto suena correcto? 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.
"Tome este caso: usted está viviendo 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 todos los objetos Persona se vinculan". Creo que cada una de esas personas tiene su propia instancia de Dirección, pero resultan ser iguales (es como si cada uno de ellos pudiera tener un billete de 5 dólares, pero eso no significa que sea el mismo billete) – Prokurors
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 manera 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.
He preguntado 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, se produce el desorden 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.
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 materia de identidad de aplicaciones de mensajería para el objeto de dirección
3 distinción entre Entities y Value Objects
Identificador vs igualdad estructural: entidades tienen identificador, las entidades son iguales 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 tienen identificador.
Mutabilidad frente a inmutabilidad: Los objetos de valor son estructuras de datos inmutables mientras que las entidades cambian durante su vida .
Vida útil: Valor objetos deben pertenecer a entidades
Tipos de valor:
entidades:
Aquí escribí una lista completa (OMI) de las diferencias entre los dos: http: // enterprisecraftsmanship. com/2016/01/11/entity-vs-value-object-the-ultimate-list-of-differences/ – Vladimir