Eu tenho uma dúvida sobre a diferença entre value object x entity.
Imagina q vc tem uma class pedido e nesta vc tem uma propriedade situacao do pedido que eh uma outra class e não eh uma enum. Esta situacao recupera suas informacoes de um banco de dados, por exemplo.
Este objeto Situacao eh um V.O ou uma Entity? Pq normalmente no sistema vc testa a situacao a partir do seu identificador, logo se vc mudar a descricao o ciclo de vida continua inalterado, mas por outro lado esta entidade foi criada para descrever a Entity pedido.
Esse objeto situação com certeza é um VO. Veja que um objeto representando a situação “Pedido cancelado” pode ser trocado por outro que represente a mesma situação sem nenhum problema.
Perceba que não precisa existir uma tabela pra gravar as situações - essa restrição pode ser implementada no banco criando-se um check, por exemplo. Mas caso resolva criar a tabela, use a própria descrição da situação como chave primária.
Eu tenho uma dúvida sobre a diferença entre value object x entity.
Imagina q vc tem uma class pedido e nesta vc tem uma propriedade situacao do pedido que eh uma outra class e não eh uma enum. Esta situacao recupera suas informacoes de um banco de dados, por exemplo.
Este objeto Situacao eh um V.O ou uma Entity? Pq normalmente no sistema vc testa a situacao a partir do seu identificador, logo se vc mudar a descricao o ciclo de vida continua inalterado, mas por outro lado esta entidade foi criada para descrever a Entity pedido.
[/quote]
Perguntinha dificil. Um VO é normalmente um objeto que representa um valor. Um situação não é um valor, embora se possa argumentar que ela representa o valor de um dos estados de um ciclo.
Neste caso - porque representa estado - sempre haverão outros valores para os outros estados . Podemos ver isto como uma enumeração. Mesmo que não seja implementado usando enum, não deixa de ser uma enumeração. Ou podemos ver como um objeto que implementa o padrão State. Podemos pensar num State Value Object mas para isso a classe tem que ter métodos que calculem o estado seguinte baseados num acção e no estado atual - como numa máquina de estados.
Mesmo tendo um id no banco a identidade desta classe não de diferencia do seu valor, da mesma forma que um Date, por exemplo. Então , embora tenha id e fique no banco não é uma entidade.
Mas isto não é tão simples assim. Podemos pensar que sim é uma entidade porque pode ser manipulada em separado do pedido. Mesmo que não seja, isso só a tornaria uma entidade adjunta a uma entidade agregada que é o pedido. Sendo que a situação é do pedido e de nada mais, ela só faz sentido associada ao pedido.
Embora meu voto vá para algo mais VO não acho que é um VO realmente, nem uma entidade realmente. Seria algo mais como um State… a questão é : que difrença faz saber como classificar esse objecto ?
Finalmente alguém respondeu com um pouco de cautela a esta questão. Sinceramente a dúvida é só conceitual mesmo, pois pensei q em DDD eu necessariamente precisava classifcar os objetos mesmo q não fisicamente como Entity ou V.O. Pelo q vc me disse eu posso classificar meus objetos de outras formas…