"Implementando DDD" por Vernon: ¿objeto de valor o no?

En la página 382 de este libro hay un pasaje que habla sobre el uso de objetos de valor en agregados, debajo de la raíz (entidad). Hay un ejemplo de Producteso, además de otros valores, contiene una Set<ProductBacklogItem>colección de entidades .

Ahora, Vernon intenta explicar por qué ProductBacklogItemes una entidad y no un objeto de valor:

Hay buenas razones por las que ProductBacklogItem se modela como una Entidad en lugar de un Valor. Como se discutió en Value Objects (6), dado que la base de datos de respaldo se utiliza a través de Hibernate, debe modelar colecciones de valores como entidades de bases de datos. Reordenar cualquiera de los elementos podría causar que se elimine y reemplace un número significativo, incluso todos, de las instancias de ProductBacklogItem. Eso tendería a causar una sobrecarga significativa en la infraestructura. Como entidad, permite que el atributo de pedido se cambie en todos y cada uno de los elementos de la colección tan a menudo como lo requiera el propietario del producto. Sin embargo, si tuviéramos que cambiar de usar Hibernate con MySQL a un almacén de valores clave, podríamos cambiar fácilmente ProductBacklogItem para que sea un tipo de Valor. Cuando se utiliza un almacén de valores o documentos clave

No entiendo por qué la implementación del repositorio determina si algún modelo será una entidad o un objeto de valor. Si vamos a la tienda de valor-clave, aún podemos tener pedidos de los que está hablando.

¿Crees que esto tiene sentido?

La razón es que las bases de datos SQL almacenan los objetos de forma relacional: los elementos se almacenan en una tabla diferente a la raíz agregada y hacen referencia a la raíz agregada por ID. Por lo tanto, el uso de MySQL requiere modelar elementos como entidades que persisten en una tabla separada donde obtienen la identificación primaria (con incremento automático).

En tiendas de valores clave, por ejemplo. MongoDB se puede almacenar toda la colección de elementos como parte de la raíz agregada. Los elementos no se convertirían en entidades separadas (en su tabla) y, por lo tanto, se pueden modelar como objetos de valor.

P.ej. El blog tiene comentarios almacenados como colección dentro de:

{
  _id: 1,
  title: 'Some title',
  body: 'Blog body',
  comments: [{
     person: 'John Smith',
     comment: 'First comment of the blog',
     created_at: new Date()
  },
  {
     person: 'Peter Jackson',
     comment: 'Second comment of the blog',
     created_at: new Date()
  }],
}

Sé que esta pregunta es de hace algunos años, pero he estado lidiando con un problema de modelado similar en este momento, y tal vez sea útil para otra persona ver qué opiniones alternativas existen.

Tiene razón, esta sección es un poco engañosa y contradictoria, ya que se dedica mucho tiempo a DDD, lo que indica que el diseño del dominio no debe ser impulsado por problemas de persistencia.

Si estoy adivinando, a lo que realmente se hace referencia es a la naturaleza inmutable de los objetos de valor. En este ejemplo, habla específicamente sobre el orden de los elementos de la cartera de pedidos. Los objetos de valor son inmutables, por lo que cambiar el orden de 1 elemento de la reserva podría dar como resultado "un número significativo, incluso todos, de las instancias de ProductBacklogItem que se eliminarán y reemplazarán".

Entonces, aunque técnicamente todavía está impulsado por la infraestructura, en última instancia para retener el orden en una solución SQL, el Objeto de valor debe ser mutable y, por lo tanto, no un Objeto de valor. Este problema no existe en una solución NoSQL donde "las instancias agregadas generalmente se serializan como una representación de valor para el almacenamiento". Por lo tanto, no debe permitir que la persistencia dirija su diseño, pero para permitir el reordenamiento no hay forma de evitar que el objeto sea una Entidad

Aquí es donde apareció mi propio problema de modelado. Si el orden de los elementos es importante, entonces he estado luchando con la idea de que esos objetos deben ser Entidades ... porque si el orden es importante, la identificación también debe ser importante. es decir. ¿Cómo reordenar artículos si cada uno no tiene una identidad específica? Si el orden no es importante, ahora es solo una colección / bolsa de valores, por lo que ahora es probable que sean objetos de valor.

El enfoque que he estado considerando es que el orden debe ser mantenido por una Entidad, en este caso OrderedBackLogItem. Pero esta entidad contiene un objeto de valor ProductBacklogItem y un atributo de pedido.

Otras alternativas son el enfoque que Vernon ha tomado (una Entidad), o la colección en sí misma es un Objeto de valor, por lo que la lista completa ordenada se destruye y se vuelve a crear cada vez.

Todavía tengo dos dudas sobre si cada elemento de una lista debe ser una Entidad si es importante reordenar.