En el diseño controlado por dominio, ¿cómo convierto una tabla de base de datos con una clave principal en un objeto de valor?

8

Supongamos que hay un esquema de base de datos definido de esta forma:

Person.mail_address_key ----- Address.address_key
Person.billing_address_key ----- Address.address_key

Un Person tiene una dirección de correo y una dirección de facturación. Como técnica de desnormalización, creamos una tabla Address separada. La mayoría de las veces, el mail_address_key y el billing_address_key de un solo Person tendrán el mismo valor (es decir, su clave de dirección de correo y facturación será la misma).

En mi base de datos el Address tiene una identidad (la clave de dirección). Pero, en mi modelo de dominio , no veo una razón convincente para que Address sea una Entidad, me gustaría que fuera un Objeto de valor.

  1. En DDD, ¿es esta una opción? ¿O son los objetos de valor generalmente un grupo de columnas (a diferencia de una tabla)? Estoy actuando como un defensor del diablo aquí, porque no creo que la base de datos deba dictar la estructura del modelo de dominio, sino asegurarme.
  2. Si es así, ¿dónde / cuándo / cómo pierde la dirección su identidad de base de datos para que pueda usarse como un Objeto de Valor en la Capa de Dominio? O, ¿se supone que debo mantener el identificador de la base de datos en el Objeto de valor?
  3. Cuando el modelo debe persistir en la base de datos, ¿cuál es el proceso? ¿Se supone que debo pasar por un proceso de a) encontrar una dirección en estos campos, b) si no existe, crear una nueva c) si es así, actualizar los campos?
pregunta Daniel Kaplan 06.10.2014 - 21:06

3 respuestas

2
  

En DDD, ¿es esta una opción? ¿O son los objetos de valor generalmente un grupo de columnas (a diferencia de una tabla)? Estoy actuando como un defensor del diablo aquí, porque no creo que la base de datos deba dictar la estructura del modelo de dominio, sino asegurarme.

La base de datos no debe dictar la estructura del modelo de dominio para que tenga razón al respecto. Los objetos de valor se pueden almacenar en la base de datos como una columna o tabla, dependiendo del tipo de datos que se supone que debe transportar el objeto de valor.

  

Si es así, ¿dónde / cuándo / cómo pierde la dirección su identidad de base de datos para que pueda utilizarse como un objeto de valor en la capa de dominio? O, ¿se supone que debo mantener el identificador de la base de datos en el Objeto de valor?

Su código de dominio no debe estar lleno de propiedades que son para otras preocupaciones como la persistencia, ya que deben ser completamente ignorantes. Realmente deberías enfocarte en tu raíz agregada. Debe tener alguna forma de identificar su raíz agregada cuando la guarde de nuevo en la base de datos, por lo que, en ese momento, solo tendría que verificar el registro de la tabla de Personas (supongo que Persona es su raíz agregada) y ver si hay un valor en el campo MailingAddressID o BillingAddressID. En ese momento, puedes decidir si crear nuevas direcciones y cambiar los enlaces para que apunten a las nuevas direcciones o sobrescribir las direcciones que ya están vinculadas.

  

Cuando el modelo debe persistir en la base de datos, ¿cuál es el proceso? ¿Se supone que debo pasar por un proceso de a) encontrar una dirección en estos campos, b) si no existe, crear una nueva c) si es así, actualizar los campos?

Como lo expliqué un poco en la respuesta anterior, debes hidratar y deshidratar tu gráfico de objetos según tu raíz agregada. Por lo tanto, cuando su repositorio obtiene su raíz agregada de la base de datos, también hidratará todas las entidades y objetos de valor necesarios bajo su raíz agregada que están asociados con su raíz agregada en la base de datos. Lo mismo ocurre cuando va a guardar la raíz agregada de nuevo en la base de datos. Su repositorio debe poder manejar todo su gráfico de objetos bajo la raíz agregada.

    
respondido por el Aaron Hawkins 30.10.2014 - 16:23
2

DDD no aplica el esquema de base de datos en absoluto. El objeto de valor puede implementarse como un grupo de columnas, entidad db (su tercera solución) o simplemente en una forma desnormalizada si puede usar una base de datos orientada a documentos, por ejemplo. Depende de las diferentes circunstancias, cuál es la mejor opción para ir con.

Tenga en cuenta que DB es solo una herramienta para mantener el estado de su dominio. No debe forzar ninguna decisión de diseño. Si, por alguna razón, tiene que usar la identidad para la representación de su objeto de valor en la base de datos, hágalo, pero no filtre este detalle de implementación en el propio dominio. Cree un contenedor / extienda las clases de dominio / lo que su marco permita y agregue el ID en una clase de infraestructura completamente separada que permita a la aplicación / marco persistir en el estado.

    
respondido por el Mequrel 07.10.2014 - 23:53
-1

No veo ningún requisito especial de DDD en este caso, puede modelar las direcciones de correo y facturación como propiedades de la persona y aún almacenarlas en una tabla separada, por ejemplo:

Person
+ MailingAddress : Address
+ BillingAddress : Address

o

Person
+ MailingAddressID
+ MailingAddress : Address
+ BillingAddressID
+ BillingAddress : Address
    
respondido por el Tien Do 08.10.2014 - 03:16

Lea otras preguntas en las etiquetas