cómo modelar las relaciones entre objetos de valor?

Question

Contexto:
Tengo una entidad libro. Un libro puede tener una o más descripciones. Las descripciones son objetos de valor.

problema:
Una descripción puede ser más específica que la otra descripción. Por ejemplo, si una descripción contiene el contenido del libro y cómo se ve la tapa es más específico que una descripción que únicamente se describe el aspecto de la cubierta. No sé cómo modelar esto y cómo hacer que el repositorio de guardarlo. No es responsabilidad del libro ni de la descripción del libro a conocer estas relaciones. Algún otro objeto puede manejar esto y luego pedir el depósito para guardar las relaciones. Pero BookRepository.addMoreSpecificDescription (Descripción, MoreSpecificDescription) parece difícil para el repositorio para guardar.

¿Cómo se maneja tal cosa en DDD?

Answer 1

Las otras dos respuestas son una dirección (1 por cierto). Estoy llegando después de editar la pregunta original, así que aquí están mis dos centavos ...

defino un objeto de valor como un objeto con dos o más propiedades que pueden (y es) compartidos entre otras entidades. Pueden ser compartidos sólo dentro de un único agregado Raíz, eso también está bien. Sólo el hecho de que se puede (y son) compartidas.

Para utilizar el ejemplo, se define una "Descripción" como un objeto de valor. Eso me dice que "Descripción" con múltiples propiedades puede ser compartida entre varios libros. En el mundo real, que no tiene sentido, como todos sabemos cada libro tiene descripciones únicas escritas por el maestro del que fue autor o publicó el libro. Jeje. Por lo tanto, yo diría que las descripciones no son realmente objetos de valor, pero sí son objetos adicionales entidad dentro de su boundery contable agregado de raíz de entidad (se pueden tener varias entidades dentro de una única entidad de raíz agregada). Incluso los libros que se soltó de nuevo, una nueva revisión, etc tienen ligeramente diferentes descripciones que describen ese ligero cambio.

Creo que eso responde a tu pregunta - hacer que los objetos de entidad descripciones y protegerlos detrás de su principal libro Entidad agregado raíz (por ejemplo Book.GetDescriptions () ...). El resto de esta respuesta direcciones cómo manejar objetos de valor en repositorios, para otros leyendo este post ...

Para el almacenamiento de objetos de valor en un repositorio, y la recuperación de ellos, empezamos a invadir en el mismo territorio Luché conmigo mismo cuando fui cambiado de un "Base de datos primero" enfoque de modelado de un enfoque DDD. Yo mismo wreslted con éste, sobre cómo almacenar un objeto de valor en el PP, y recuperarlo sin identidad. Hasta que di un paso atrás y se dio cuenta lo que estaba haciendo ...

En Domain Driven Design, que está modelando los objetos de valor en su dominio - no el almacén de datos. Esa es la frase clave. Esto significa que no es el diseño de los objetos de valor que se almacena como objetos independientes en el almacén de datos, puede guardarlos como usted quiera!

Tomemos el ejemplo común DDD de Valor objetos, que al ser una dirección (). DDD presenta que una dirección de correo es el ejemplo perfecto valor de los objetos, como la definición de un objeto de valor es un objeto de que sus propiedades resumen para crear la singularidad del objeto. Si una propiedad cambia, será de un valor de objeto diferente. Y el mismo valor de la suma 9teh objeto de sus propiedades) puede ser compartida entre otras entidades.

Una dirección de correo es un lugar, una larga / lat de una ubicación específica en el planeta. Varias personas pueden vivir en la dirección, y cuando alguien se mueve, la gente nueva a ocupar la misma Dirección de Correo ahora usan el mismo valor de los objetos.

Por lo tanto, tengo un objeto Person () con un objeto MailingAddress () que tiene la información de dirección en ella. Está protegido detrás de mi persona () raíz agregada con / actualizar / crear métodos / servicios de conseguir.

Ahora, ¿cómo almacenamos eso y compartirlo entre las personas en la misma casa? Ah, ahí está DDD - no se está modelando el almacén de datos directamente desde el DDD (aunque, eso sería bueno). Dicho esto, usted sencilla crear una sola tabla que presenta el objeto Person, y tiene las columnas de su dirección postal dentro de ella. Es el trabajo de su repositorio para rehidratar que la información de nuevo en su persona () y MailingAddress () objeto del almacén de datos, ya que se dividió durante las operaciones de Crear / Actualizar.

Sí, tendrías datos duplicados ahora en el almacén de datos. Tres persona () entidades con la misma dirección de correo todos ahora tienen tres copias separadas de que los datos de objetos de valor - y que es aceptable! Los objetos de valor están destinados a ser copiado y destoyed con bastante facilidad. "Copia" es la palabra óptima allí en el libro de jugadas DDD.

Para resumir, el dominio de diseño del modelado se trata de su dominio para representar su uso comercial real de los objetos. Crea un modelo de Person () y una entidad Valor MailingAddress objetos por separado, ya que están representados de manera diferente en su aplicación. Se les persisten a-datos copiados, que siendo columnas adicionales en la misma mesa que su mesa persona.

Todo lo anterior es estricta-DDD. Pero, DDD está destinado a ser sólo "sugerencias", no reglas para vivir. Es por eso que usted es libre de hacer lo que yo y muchos otros han hecho, una especie de estilo suelto-DDD. Si no te gusta los datos copiados, su única opción es que el ser puede crear una tabla separada para MailingAddress () y se adhieren una columna de identidad en él, y actualizar su MailingAddress objeto () para tener ahora tienen esa identidad en él - sabiendo que sólo utiliza la identidad de vincularlo a otra persona () objetos que lo comparten (yo personalmente como una tercera tabla de relación de muchos a muchos, para mantener la velocidad de las consultas en adelante). Se podría enmascarar que Idenity (es decir modificador interno) de la exposición fuera de su agregado Raíz / dominio, por lo demás capas (tales como la aplicación o interfaz de usuario) no sabe de la columna de identidad de la MailingAddress, si es posible. También, me gustaría crear un repositorio dedicado sólo para MailingAddress, y usar su capa PersonService combinarlos en el objeto correcto, Person.MailingAddress ().

Lo siento por la diatriba ...:)

Answer 2

En primer lugar, creo que los exámenes deben ser entidades.

En segundo lugar, ¿por qué estás tratando de modelar las relaciones entre los exámenes? No veo una relación natural entre ellos. "Más específico que" es demasiado vaga para ser útil como una relación.

Si usted está teniendo dificultades para modelar la situación, eso sugiere que tal vez no hay ninguna relación.

Answer 3

Estoy de acuerdo con Jason. No sé lo que su razón es para la fabricación de objetos de valor revisión.

Yo esperaría una Revisión de libros para tener BookReviewContentItems por lo que podría tener un método en la Revisión de libros de llamar para decidir si es lo suficientemente específica, donde el método decide, basándose en la consulta de su colección de elementos de contenido.