“Implementando DDD” por Vernon: valor objeto ou não?

Na página 382 deste livro, há uma passagem falando sobre o uso de objetos de valor em agregados, sob a raiz (entidade). Há um exemplo Productdisso, além de outros valores, que contém uma Set<ProductBacklogItem>coleção de entidades .

Agora, Vernon tenta explicar por que ProductBacklogItemuma entidade e não um objeto de valor:

Existem boas razões pelas quais ProductBacklogItem é modelado como uma Entidade e não como um Valor. Conforme discutido em Value Objects (6), como o banco de dados de backup é usado via Hibernate, ele deve modelar coleções de valores como entidades do banco de dados. Reordenar qualquer um dos elementos pode fazer com que um número significativo, mesmo todos, das instâncias ProductBacklogItem sejam excluídos e substituídos. Isso tenderia a causar uma sobrecarga significativa na infraestrutura. Como uma entidade, ele permite que o atributo de pedido seja alterado em todo e qualquer elemento da coleção quantas vezes for necessário para o proprietário de um produto. No entanto, se deixarmos de usar o Hibernate com MySQL para um armazenamento de valores-chave, poderíamos facilmente mudar ProductBacklogItem para um tipo Value. Ao usar um valor-chave ou armazenamento de documentos,

Não entendo por que a implementação do Repositório determina se algum modelo será um Objeto de Entidade ou Valor. Se formos à loja de valores-chave, ainda podemos ter pedidos sobre os quais ele está falando.

Você acha que isso faz sentido?

O motivo é que os bancos de dados SQL armazenam os objetos de maneira relacional - os itens são armazenados em uma tabela diferente da raiz agregada e fazem referência novamente à raiz agregada por IDs. Portanto, o uso do MySQL exige modelar itens como entidades que são persistidas em uma tabela separada, onde eles obtêm o ID primário (com incremento automático).

Em lojas de valores-chave, por exemplo. O MongoDB pode armazenar toda a coleção de itens como parte da raiz agregada. Os itens não se tornariam entidades separadas (na tabela) e, portanto, podem ser modelados como objetos de valor.

Por exemplo. O blog possui Comentários armazenados como coleção em:

{
  _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()
  }],
}

Sei que essa pergunta é de alguns anos atrás, mas estou lidando com um problema de modelagem semelhante no momento, e talvez seja útil para outra pessoa ver quais opiniões alternativas existem por aí.

Você está certo, esta seção é um pouco enganadora e contraditória, pois tanto tempo é gasto no DDD indicando que o design do domínio não deve ser conduzido por preocupações de persistência.

Se estou tentando adivinhar, o que realmente está sendo referido é a natureza imutável dos Objetos de Valor. Neste exemplo, ele fala especificamente sobre o pedido dos itens da lista de pendências. Os Objetos de Valor são imutáveis, portanto, alterar a ordem de 1 Item da Lista de pendências pode resultar em "um número significativo, mesmo todas, das instâncias do ProductBacklogItem a serem excluídas e substituídas".

Portanto, embora tecnicamente ainda seja impulsionado pela infraestrutura, em última análise, para manter a ordem em uma solução SQL, o Value Object deve ser mutável e, portanto, não um Value Object. Esse problema não existe em uma solução NoSQL em que "Instâncias agregadas geralmente são serializadas como uma representação de valor para armazenamento". Portanto, você não deve deixar a persistência orientar seu design, mas para permitir o reordenamento, não há como evitar que o objeto seja uma Entidade

Foi aqui que meu próprio problema de modelagem entrou em cena. Se a ordem dos itens for importante, estive lutando com a idéia de que esses objetos devem ser Entidades ... porque se a ordem é importante, a identificação também deve ser importante. ie Como você reordena os itens se cada um não possui uma identidade específica? Se a ordem não é importante, agora é apenas uma coleção / conjunto de valores e, agora, eles provavelmente são objetos de valor.

A abordagem que eu estou considerando é que o pedido deve ser mantido por uma Entidade, neste caso OrderedBackLogItem. Mas essa entidade contém um Objeto de valor ProductBacklogItem e um atributo de pedido.

Outras alternativas são a abordagem adotada por Vernon (uma entidade) ou a coleção em si é um objeto de valor e, portanto, toda a lista ordenada é destruída e recriada a cada vez.

Ainda estou em dúvida se cada item de uma lista deve ser uma Entidade se a reordenação for importante.