DDD: ¿Puede un objeto de valor tener listas dentro de ellos?

Question

No conozco bien el diseño dirigido por dominios y recientemente comencé a crear un modelo de dominio para un proyecto. Todavía no me he decidido por un ORM (aunque probablemente iré con NHibernate) y actualmente estoy tratando de asegurarme de que mis Value Objects deberían ser solo eso.

Tengo algunos VO que casi no tienen otro comportamiento que encapsular "like" términos, por ejemplo:

public class Referral {
    public Case Case { get; set; } // this is the a reference to the aggregate root
    public ReferralType ReferralType { get; set; } // this is an enum
    public string ReferralTypeOther { get; set; }
} // etc, etc.

Esta clase particular tiene una referencia a " Case " que está dos niveles arriba, así que si digo que voy a acceder a una Referencia, podría ir: case.social.referral (Case, Social y Referral son todas clases, hay un solo Social dentro de un Caso y hay una sola Referencia dentro un social). Ahora que lo estoy viendo mientras lo escribo, no creo que necesite un Caso en la Referencia ya que será accesible a través de la entidad Social, ¿correcto?

Ahora, no hay duda en mi mente, esto es algo que debería ser un VO, y el método que planeo usar para persistir esto en la base de datos es hacer que NHibernate le asigne un identificador sustituto (que todavía no soy demasiado claro, si alguien pudiera explicarlo también, eso me ayudaría, ya que no sé si el identificador sustituto requiere que ya tenga un Id en mi VO o si puede funcionar sin uno) y / o un propiedad de identificación protegida que no estaría expuesta fuera de la clase de referencia (con el único propósito de persistir en la base de datos).

Ahora a mi pregunta sobre el título: ¿Debería un VO tener una colección (en mi caso, una Lista) dentro? Solo puedo pensar en esto como una relación de uno a muchos en la base de datos, pero como no hay identidad, no parecía adecuado hacer de la clase una entidad. A continuación se muestra el código:

public class LivingSituation {
    private IList<AdultAtHome> AdultsAtHome { get; set; }
    public ResidingWith CurrentlyResidingWith { get; set } // this is an enum
} // etc, etc.

Esta clase actualmente no tiene un Id y la clase AdultsAtHome solo tiene tipos intrínsecos (string, int). Por lo tanto, no estoy seguro de si esto debería ser una entidad o si puede permanecer como un VO y solo necesito configurar mi ORM para usar una relación 1: m para esto usando sus propias tablas y un campo de Id privado / protegido para que el ORM puede persistir en la base de datos.

Además, ¿debo ir con tablas normalizadas para cada una de mis clases, o no? Creo que solo necesitaría usar una tabla por clase cuando existe la posibilidad de tener varias instancias de la clase asignadas a una entidad u objeto de valor y / o existe la posibilidad de tener relaciones de colecciones 1: m con algunos de esos objetos . No tengo ningún problema con el uso de una sola tabla para ciertos objetos de valor que tienen tipos intrínsecos, pero con los tipos anidados creo que sería ventajoso usar tablas normalizadas. ¿Alguna sugerencia sobre esto también?

Perdón por ser tan detallado con las múltiples preguntas:

1) ¿Necesito un identificador sustituto (con digamos NHibernate) para mis objetos de valor?

2) Si el # 1 es sí, entonces esto debe ser privado / protegido para que mi objeto de valor '' permanezca '' ¿Un objeto de valor en concepto?

3) ¿Puede un objeto de valor tener otros objetos de valor (por ejemplo, una Lista) o constituiría una entidad? (Creo que la respuesta a esto es no, pero preferiría estar seguro antes de continuar).

4) ¿Necesito una referencia a la raíz agregada de un objeto de valor que esté unos niveles por debajo de la raíz agregada? (No creo que lo haga, es probable que sea un descuido de mi parte al escribir el modelo, ¿alguien está de acuerdo?)

5) ¿Está bien usar tablas normalizadas para ciertas cosas (como tipos anidados y / o tipos con colecciones como propiedades que de todos modos necesitarían sus propias tablas para la relación 1: m) mientras el ORM realiza la asignación para el ¿objetos de valor más simples a la misma tabla que pertenece a mi entidad?

Gracias de nuevo.

Answer 1

Eche un vistazo a las respuestas a preguntas relacionadas aquí y aquí

---

1) Sí - Si está almacenando VOs en su propia tabla

2) Si puede usar una propiedad de identificación privada / protegida, entonces genial. Alternativamente, puede usar interfaces explícitas para 'ocultar' la propiedad ID.

Pero, leyendo su pregunta, ¿está sugiriendo que los desarrolladores que ven una propiedad de ID asumirán automáticamente que el objeto es una entidad? Si es así, necesitan (re) capacitación.

3) Sí, pero con las siguientes restricciones:

• Debería ser bastante raro
• Solo debe hacer referencia a otras VO

Además, considere esto: los VO no deberían quedarse. ¿Sería fácil / eficiente recrear todo el VO cada vez que sea necesario? Si no, conviértalo en una entidad.

4) Depende de cómo desee implementar su Bloqueo Agregado . Si desea utilizar Solución de Ayende , la respuesta es sí. De lo contrario, necesitaría un mecanismo para atravesar el gráfico del objeto de regreso a la raíz agregada.

5) Sí. No olvide que DDD es Ignorante de persistencia (¡en un mundo ideal!).

---

Sin embargo ...

Creo que la recomendación debe ser una entidad . Imagina estas conversaciones:

Conversación 1:

• Tom: " ¡Hola Joe! ¿Me puede dar la referencia de David Jone? & Quot;
• Joe: "¿Cuál?"
• Tom: " Lo siento, me refiero a la referencia n. ° 123 "

Conversación 2:

• Tom: " ¡Hola Joe! ¿Me puede dar la referencia de David Jone? & Quot;
• Joe: " ¿Cuál? "
• Tom: `` No me importa, solo dame cualquiera ''

La conversación 1 sugiere que la Referencia es una Entidad , mientras que la conversación 2 sugiere que es una VO.

Una cosa más: ¿ Referral.ReferralType cambia durante su vida útil (hay otra pista de que debería ser una Entidad)? Si no cambia, considere la posibilidad de utilizar el polyporphism y deje que NH lo maneje.

¡Espero que eso ayude!