Questão de Engenharia de Software — Metodologia de desenvolvimento de software — INSTITUTO AOCP 2025

Domain-Driven Design (DDD): Objetos de Valor

Gabarito: letra C. O conceito descrito no enunciado — blocos de construção do DDD que representam conceitos imutáveis e autocontidos, sem identidade própria, definidos por seus atributos — corresponde exatamente aos objetos de valor (Value Objects), um dos elementos centrais do Domain-Driven Design. A alternativa correta é a letra C.

O Domain-Driven Design (DDD) é uma abordagem de desenvolvimento de software que centra o esforço na modelagem do domínio do negócio, ou seja, nas regras e processos que definem a área de atuação do sistema. Em vez de começar pela infraestrutura técnica, o DDD parte do entendimento profundo do negócio para construir um modelo de domínio rico e expressivo. Essa abordagem foi popularizada por Eric Evans em seu livro "Domain-Driven Design: Tackling Complexity in the Heart of Software" (2003), e se apoia em três pilares fundamentais: a linguagem ubíqua, os contextos delimitados e os mapas de contexto. A linguagem ubíqua é um vocabulário compartilhado entre todos os envolvidos no projeto — desenvolvedores, especialistas de negócio, usuários — para garantir que todos falem a mesma língua e evitem ambiguidades. Os contextos delimitados (bounded contexts) são a divisão do sistema em módulos com responsabilidades claras e distintas, cada um com seu próprio modelo de domínio. Os mapas de contexto, por sua vez, descrevem como esses contextos se comunicam entre si.

Dentro do modelo de domínio, o DDD define blocos de construção que ajudam a estruturar o código de forma fiel ao negócio. Os principais são: Entidades (Entity), Objetos de Valor (Value Object), Agregados (Aggregate), Serviços de Domínio (Domain Service), Repositórios (Repository) e Fábricas (Factory). A distinção entre Entidade e Objeto de Valor é uma das mais importantes e cobradas em provas. Uma Entidade possui identidade própria e contínua — mesmo que seus atributos mudem, ela continua sendo a mesma coisa. Por exemplo, uma pessoa com CPF, um pedido com número, um cliente com ID. Já um Objeto de Valor é definido exclusivamente por seus atributos e é imutável — não possui identidade própria. Se dois objetos de valor têm os mesmos atributos, eles são considerados iguais. Um exemplo clássico é um endereço: se você muda a rua, o CEP e a cidade, o endereço é outro; não faz sentido perguntar "qual é a identidade deste endereço?". Outros exemplos: dinheiro (valor + moeda), cor (RGB), data, intervalo de tempo.

A imutabilidade é uma característica crucial: um objeto de valor não deve ser alterado após sua criação. Se for necessário mudar algo, cria-se um novo objeto. Isso traz segurança e evita efeitos colaterais indesejados. A autocontenção significa que o objeto carrega consigo todo o seu significado, sem depender de um contexto externo para ser compreendido. Essas propriedades fazem dos objetos de valor excelentes para representar conceitos do domínio que são descritos por suas características intrínsecas.

A pegadinha desta questão está em confundir os objetos de valor com outros conceitos do DDD. A linguagem ubíqua é o vocabulário comum, não um bloco de construção. Os contextos delimitados são a divisão do sistema em módulos. Os eventos de domínio são fatos que ocorreram no domínio e que interessam a outras partes do sistema. E o modelo de domínio é a representação abstrata do domínio como um todo, não um bloco de construção específico. A banca explora exatamente essa confusão entre os pilares do DDD e os blocos de construção.

Guarde a fronteira entre Entidade (tem identidade) e Objeto de Valor (não tem identidade, é definido por atributos): é exatamente nela que as alternativas se dividem.

Alternativa A — ❌ Incorreta

A linguagem ubíqua é um dos três pilares do DDD, definida como a linguagem compartilhada por todos os membros da equipe e partes interessadas do negócio. Ela não é um bloco de construção do modelo de domínio, mas sim um mecanismo de comunicação para alinhar o vocabulário. O enunciado fala de conceitos imutáveis e autocontidos sem identidade própria, o que não se aplica à linguagem ubíqua.

Alternativa B — ❌ Incorreta

Os contextos delimitados (bounded contexts) são outro pilar do DDD, responsáveis pela separação de responsabilidades entre as diferentes partes do sistema. Eles dividem o sistema em módulos com responsabilidades claras, mas não são blocos de construção que representam conceitos imutáveis e sem identidade. São, na verdade, a delimitação de fronteiras dentro do domínio.

Alternativa C — ✅ Correta ⟵ GABARITO

Os objetos de valor (Value Objects) são exatamente o que o enunciado descreve: blocos de construção do DDD que representam conceitos imutáveis e autocontidos, sem identidade própria, definidos por seus atributos. Eles são a alternativa correta, pois capturam a essência da definição apresentada.

Alternativa D — ❌ Incorreta

Os eventos de domínio são fatos que ocorreram no domínio e que são relevantes para outras partes do sistema. Eles representam algo que aconteceu (ex.: "pedido confirmado", "pagamento recebido") e não são imutáveis nem definidos apenas por atributos — são ocorrências no tempo, com identidade própria (cada evento é único).

Alternativa E — ❌ Incorreta

O modelo de domínio é a representação abstrata do domínio como um todo, a base da comunicação do projeto. Ele não é um bloco de construção específico, mas sim o resultado da modelagem do domínio. O enunciado pede um conceito que é um bloco de construção, e o modelo de domínio é mais amplo, englobando entidades, objetos de valor, agregados, etc.

Gabarito: letra C