Em DDD, como identificar, facilmente, uma “entidade” e um “objeto de valor”?  Em debates sobre DDD, embora, esse não seja o tema mais fundamental, sem dúvidas, é o um dos mais recorrentes.

Para tentar responder a questão acima, evitamos definições conceituais mais profundas (que são muito bem tratadas nos livros do Evans e do Vernon) e indicamos critérios mais objetivos.

Comparação

Para definir se dois objetos, mesmo que de tipos diferentes, estão descrevendo uma mesma “entidade”, devemos fazer a comparação, invariavelmente, pelos seus Id.

Observe que é plenamente razoável que uma mesma entidade tenha duas (ou mais) representações (implementações em tipos diferentes), em um mesmo contexto ou em contextos diferentes. É o Id que irá definir qual entidade está sendo representada.

Para definir se dois objetos referenciam um mesmo “objeto de valor”, deve-se comparar, de forma completa, seus estados. Se o conjunto de campos dos dois objetos forem exatamente os mesmos, e estes tiverem com os mesmos valores, estamos tratando de um mesmo “objeto de valor”.

Uma das maiores aberrações (e fontes de confusão) da adoção de modelos de persistência (para bases relacionais) como modelos de domínio é fazer com que “objetos de valor” tenham um Id.

Já vimos “gente boa” argumentando que em seu domínio só haviam entidades, pois todos os tipos tinham um Id (que era imposto pelo banco, e não pelo domínio). Não cometa o mesmo erro!

Imutabilidade

O estado das entidades é, naturalmente, mutável. Enquanto isso, objetos de valor são, por definição, imutáveis.

Não devemos assumir que implementações de entidades em classes imutáveis são uma característica do domínio. 

Implementações de classes em tipos imutáveis, onde mudanças geram novas instâncias, é uma prática interessante (que recomendo, inclusive). Mas, é preciso entender que, mesmo com essa técnica de implementação, conceitualmente, a entidade tem seu estado alterado a cada nova versão. Nesses cenários, cada instância é um “registro” do estado da entidade em um determinado momento.

Quando precisamos mudar o valor de um “objeto de valor”, estamos, na prática, definindo um novo “objeto de valor”. Por exemplo, não “alteramos um endereço”, mas sim “definimos um novo enderenço”.

Implementação

Pelas características que descrevemos acima, em C#, “entidades” são mais naturalmente implementáveis como classes, “objetos de valor” são mais naturalmente implementáveis como estruturas (BTW, siga os links para entender as implicações técnicas na escolha de classes e estruturas).

É comum ver “objetos de valor” representados como tipos primitivos (principalmente, quando tem apenas um “campo”). Entendemos essa prática como imprecisa e não a recomendamos.

Finalizando

Mais uma vez, recomendamos muito que, antes de tentar definir precisamente o que é uma “entidade” e o que é um “objeto de valor”, você realmente invista seu tempo entendendo a linguagem onipresente.  Entretanto, como uma coisa não exclui a outra, ao começar a definir a estrutura de dados da sua aplicação, em caso de dúvidas, tente recorrer sempre a critérios objetivos.