Solucionado (ver solução)
Solucionado
(ver solução)
8
respostas

Entidade "Especialidade" e DDD

Fala mestre,

No meu modelo de domínio a especialidade poderia ser um value object? A minha pergunta é por que parece ser apenas um valor imutável e sem um ciclo de vida próprio. Só que se a resposta for afirmativa me leva a outros questionamentos em relação a persistência por que realmente eu preciso de uma tabela e um identificador.

Isso me levou a pensar em outros, como por exemplo, um endereço. Um endereço parece ter todos atributos para ser um value object mas sempre tratei como uma entidade pela necessidade de precisar ter uma tabela própria e um identificador para os relacionamentos.

Estou pensando muita besteira ou realmente isso é confuso no DDD? Poderia me dizer algo sobre esses casos?

8 respostas
solução!

Realmente existe certa confusão sobre persistência de Value Objects, Diego.

Value Objects não possuem identidade. São Paulo é São Paulo e pronto. Não precisa de um CNPJ pra cidade, por exemplo.

Mas para o banco de dados, esse conceito não existe. Todo registro precisa de um id. Então nesse caso é comum usarmos o que é conhecido como surrogate id. Ela não existe no domínio, mas sim no banco. Então no Doctrine nós normalmente só mapeamos a propriedade sem adicionar nehum método de acesso para ela.

É uma espécie de gambiarra, mas resolve. rsrs

Me diz se eu tirei sua dúvida ou se compliquei mais as coisas.

Então mestre, entendi sim.

Porém, voltando ao mesmo exemplo dos endereços. Eu adiciono um endereço, que é um value object, para uma entidade Usuario, então o doctrine salva meu endereço na tabela e cria um id para ele via processo surrogate. Se eu criar o mesmo endereço para outro Usuario vou acabar duplicando o registro desse endereço, nesse caso devo tratar endereço como uma entidade mesmo que teoricamente ele seja um value object?

Aí são detalhes de persistência, não de negócio. Pro negócio, o Endereço é o mesmo, entende? Se no banco de dados vão ser 2 registros ou 1 só no banco, não importa pra pra pessoa que vai mandar o boleto pra esse usuário.

:-p

Nesse caso então, no meu repositório, faço uma verificação se já existe o valor daquele endereço na tabela de endereços e se já existir em vez de criar um novo registro atribuo ao meu usuário aquele endereço já existente? Partindo do principio que posso ter usuários com o mesmo endereço e/ou mais de um endereço.

Essa é uma das opções sim, Diego. Eu honestamente repetiria o endereço no banco pra não me preocupar com isso, mas se você não quer repetir, essa verificação é uma possibilidade.

Talvez uma saída desse tipo te poupe idas ao banco: https://stackoverflow.com/questions/3164505/mysql-insert-record-if-not-exists-in-table

Valeu mestre, o problema é que com a repetição eu perderia a normalização do banco. Gostei do exemplo mostrado no link.

Resumindo tudo: Devo isolar completamente o modelo de negócios do modelo da persistência. Mesmo que o objeto de valor represente uma tabela no banco de dados, como endereços ou telefones, devo realmente tratar como objetos de valor no modelo de negócios, correto?

Exato. A camada de persistência é um mero detalhe. Se você estivesse salvando tudo em um grande JSON, nada mudaria pro negócio, entende?

:-

Sim, de fato!