DDD: objetos imutáveis ​​também podem ser entidades?


9

Eu li inúmeras postagens sobre diferenças entre objetos Entidades e Valor e, embora eu pense que pelo menos conceitualmente entendo como as duas diferem, parece que em algumas dessas postagens os autores consideram um conceito de domínio específico como um VO simplesmente porque é imutável (portanto, seu estado nunca será alterado, pelo menos dentro desse modelo de domínio específico).

Você concorda que, se o estado de um objeto nunca mudar dentro de um modelo de domínio específico, esse objeto nunca deverá ser uma entidade? Por quê?


Preciso aprender um pouco de DDD para poder responder a algumas dessas perguntas de maneira inteligente. Suspeito que a dificuldade que muitos desenvolvedores de software tenham com conceitos simples como esse decorra da noção equivocada de que DDD é uma metodologia de programação.
Robert Harvey

Respostas:


4

Seguindo o livro (Evans, 2004), "Um objeto definido principalmente por sua identidade é chamado de ENTIDADE". Essa definição é independente de o objeto ser mutável ou imutável. Eu acho que é muito menos provável que um objeto imutável seja uma entidade em um determinado domínio, por isso é uma heurística útil para decidir se um objeto é um "objeto de valor" ou uma "entidade", mas isso não faz parte da definição.

Por exemplo, digamos que você tenha uma entidade representando um funcionário, que pode ou não ter um supervisor direto. Se você decidir representar a idéia de não ter um supervisor direto como uma referência a um objeto de supervisor "nulo", o objeto de supervisor "nulo" será razoavelmente considerado uma entidade. E você provavelmente poderia tornar esse objeto "nulo" imutável.


11
+1 O gerente pode ser somente leitura (imutável) em um contexto ou subdomínio específico, mas isso não significa que não tem identidade.
Adrian Schneider

Perdoe-me por ser densa, mas não entendo completamente o exemplo do seu supervisor. Você está dizendo que no domínio teríamos dois conceitos relacionados ao supervisor? Um conceito representaria supervisores que possuem funcionários que eles supervisionam (no código esse conceito seria implementado como classe de supervisor mutável) enquanto o outro conceito descreveria supervisor que não supervisiona nenhum funcionário (e esse conceito seria implementado como nulo no código) ?
precisa saber é o seguinte

@bckpwrld Não, ele certamente significa um Objeto Nulo .
maaartinus 13/09/14

2

A maneira como eu li isso é que um objeto de valor é um objeto que não tem uma identidade em si mesmo e que nada tem a ver com o seu estado mudar ou não mudar. Isso faz a diferença entre uma entidade e um objeto de valor que uma entidade possui uma chave primária, enquanto um objeto de valor não; ele terá uma chave estrangeira para a entidade à qual pertence.

http://lostechies.com/joeocampo/2007/04/23/a-discussion-on-domain-driven-design-value-objects/

Ainda posso alterar as propriedades do objeto de valor, mas ele nunca precisa ser identificado independentemente de sua entidade.


Eu misturei terminologia de bancos de dados relacionais (chave primária) como identidade como uma metáfora, por favor, não leve isso literalmente para o lado #
Kevin Kevin

Pelo menos para meu entendimento, mesmo que no código VOs sejam representados com um tipo mutável (portanto, instâncias desse tipo podem ter suas propriedades modificadas), conceitualmente esses VOs ainda são imutáveis. Assim, alterar uma propriedade de uma instância representando um VO específico significa que agora essa mesma instância representa um VO diferente. Em outras palavras, VOS são conceitualmente sempre imutável
bckpwrld
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.