Questão de Engenharia de Software — Orientação a Objetos — FGV 2026

Domain-Driven Design: Value Objects e Entities

Gabarito: letra D. No DDD, a distinção central entre Value Object e Entity é a identidade: a Entity possui identidade própria e contínua, enquanto o Value Object é definido pelos valores de seus atributos, sendo imutável e intercambiável. A alternativa D captura a recomendação de design de priorizar Value Objects sempre que possível, pois são mais simples de criar, testar e manter — exatamente o que a banca cobra.

O Domain-Driven Design (DDD), popularizado por Eric Evans, organiza o modelo de domínio em torno de dois tipos fundamentais de objetos: Entities e Value Objects. A diferença essencial não está na estrutura, mas no conceito de identidade. Uma Entity é um objeto que possui uma identidade contínua — mesmo que seus atributos mudem, ela permanece a mesma (ex.: uma pessoa, um pedido, uma conta bancária). Já um Value Object não possui identidade própria: ele é definido inteiramente pelos valores que carrega (ex.: um endereço, uma data, um valor monetário). Dois Value Objects são iguais se seus atributos forem iguais — não importa se são objetos distintos na memória.

A regra de ouro do DDD é: Value Objects devem ser imutáveis. Uma vez criados, seus atributos não podem ser alterados; qualquer mudança gera um novo objeto. Isso elimina efeitos colaterais e torna o código mais previsível e seguro. Por isso, a recomendação prática é preferir Value Objects a Entities sempre que possível: como eles não têm identidade, são mais fáceis de criar, comparar, testar e manter. Entities devem ser reservadas para os conceitos que realmente precisam de identidade e continuidade no domínio.

A pegadinha clássica da banca é inverter as características: atribuir identidade e mutabilidade ao Value Object, ou dizer que a igualdade entre Value Objects se dá por identificadores — quando, na verdade, a igualdade é por valores. Outra armadilha é afirmar que métodos de Value Objects devem produzir efeitos colaterais, quando o correto é justamente o oposto: métodos devem retornar novos objetos, sem modificar o estado existente.

Guarde a fronteira decisiva: Entity = identidade + mutabilidade; Value Object = valores + imutabilidade. É exatamente nessa fronteira que as alternativas se dividem.

Alternativa A — ❌ Incorreta

Afirma que um Value Object tem identidade única e exclusiva e sofre mudanças contínuas de estado. Isso é o oposto do conceito: Value Objects não têm identidade e são imutáveis. A banca troca as características do Value Object pelas da Entity — armadilha clássica de inversão de papéis.

Alternativa B — ❌ Incorreta

Diz que a principal característica de um Value Object é a mutabilidade, com atributos alterados livremente após a criação. É exatamente o contrário: a principal característica é a imutabilidade. Alterar um Value Object significa criar um novo objeto, nunca modificar o existente. A banca inverte o atributo central do conceito.

Alternativa C — ❌ Incorreta

Afirma que a igualdade entre dois Value Objects é determinada pela comparação de identificadores, independentemente dos valores. Isso é falso: Value Objects não possuem identificadores — a igualdade é determinada pela comparação dos valores de seus atributos. A banca troca o critério de igualdade (valores) pelo critério de Entity (identidade).

Alternativa D — ✅ Correta ⟵ GABARITO

A alternativa correta afirma que o design deve priorizar Value Objects em vez de Entities sempre que possível, pois tipos de valor que medem, quantificam ou descrevem coisas são mais fáceis de criar, testar e manter. Isso reflete a recomendação central do DDD: como Value Objects são imutáveis e sem identidade, eles são mais simples, previsíveis e fáceis de reutilizar. A banca cobra exatamente essa diretriz de design.

Alternativa E — ❌ Incorreta

Diz que os métodos de um Value Object devem, por padrão, produzir efeitos colaterais para modificar seu próprio estado ou o de outras Entities. Isso viola o princípio da imutabilidade: métodos de Value Objects devem ser puros, retornando novos objetos sem alterar o estado existente. A banca inverte a recomendação de design, atribuindo ao Value Object o comportamento típico de objetos mutáveis.

A regra de ouro para a prova: Value Object = imutável + igualdade por valores + sem identidade; Entity = mutável + identidade contínua. Sempre que a alternativa atribuir identidade, mutabilidade ou efeitos colaterais a um Value Object, ela está errada. E lembre-se: a recomendação de design é preferir Value Objects — eles simplificam o modelo e o código.

Gabarito: letra D