DDD: Ayúdenme a comprender mejor objetos y entidades de valor

Question

Hay varias preguntas al respecto, y leerlas no me ayuda. En Eric Evans DDD, utiliza el ejemplo de la dirección como un tipo de valor en ciertas situaciones. Para una empresa de pedidos por correo, la dirección es un tipo de valor porque realmente no importa si la dirección se comparte, quién más vive en la dirección, simplemente que el paquete llega a la dirección.

Esto tiene sentido para mí hasta que empiece a pensar cómo se diseñaría esto. Teniendo en cuenta el diagrama de la página 99, que tiene así:

+------------+ 
|Customer | 
+------------+ 
|customerId | 
|name  | 
|street  | 
|city  | 
|state  | 
+------------+ 

Esto cambia a:

+------------+ 
|Customer | (entity) 
+------------+ 
|customerId | 
|name  | 
|address  | 
+------------+ 

+------------+ 
|Address  | (value object) 
+------------+ 
|street  | 
|city  | 
|state  | 
+------------+ 

Si estos fueran tablas, Dirección tendría su propia identificación con el fin de tener una relación con el cliente, convirtiéndolo en una entidad.

Es la idea de que en una base de datos relacional estos permanecerían en la misma tabla, como en el primer ejemplo, y que usaría características del ORM para abstraer la dirección como un objeto de valor (como las características del componente nHibernate)?

Me doy cuenta de que un par de páginas después habla sobre la desnormalización, solo estoy tratando de asegurarme de entender el concepto correctamente.

Answer 1

es la idea de que en una base de datos relacional éstos permanecerían en el mismo tabla, como en el primer ejemplo, y que tendrá que utilizar las características de la ORM a la dirección abstracto como un objeto de valor (como las características del componente nHibernate )?

Sí, en general, esa es la idea.

Alternativamente (si su ORM no admite objetos de valor directamente), puede permitir que las tablas de VO tengan una ID, pero la oculten dentro de su modelo de dominio.

Answer 2

Personalmente me importa un comino tener ID en objetos de valor siempre que anulen la comparación de igualdad correctamente (porque los objetos de valor difieren por su valor, no por su identidad).

La asignación de objetos de valor a la base de datos es una preocupación técnica, a veces (por ejemplo, marcar elementos virtuales para que ORM pueda rastrear por debajo). Simplemente debe sacrificar un poco la pureza del modelo de dominio. O haga que su infraestructura sea más inteligente: uso de componentes nhib o algo así.

Answer 3

Cuando Eric Evans habla sobre "las entidades tienen identidad, Value Objects no", no está hablando de una columna de ID en la base de datos, sino de la identidad como concepto.

Los VO no tienen identidad conceptual. Eso no quiere decir que no deberían tener identidad de persistencia. No permita que la implementación de persistencia oscurezca su comprensión de las Entidades frente a los VO.

Puede crear un cuadro por dirección o en la misma tabla Clientes

Answer 4

Sí, generalmente Dirección se quedaría en la misma mesa. Dirección se asigna algo como esto:

+-----------------+ 
|Customer   | 
+-----------------+ 
|customerId  | 
|name    | 
|address_street | 
|address_city  | 
|address_state | 
+-----------------+ 

Si la dirección era una entidad, entonces sería en una tabla separada, como usted ha dicho.Si dos de los mismos Clientes se vinculan a la misma entidad de Dirección, entonces cambiar un atributo de esa Dirección afectaría a ambos Clientes. Sin embargo, una implementación de VO solo afectaría a uno u otro.