Entrar Ainda não tem acesso?
Solucionado (ver solução)
Solucionado
(ver solução)
1
resposta

Value Objects para os demais campos

por REINALDO DE CARVALHO SILVA
| 40.7k xp | 10 posts

Não seria interessante estender o uso de Value Objects para os demais atributos das Entidades?

CRM e Nome poderiam ser Value Objects, e na minha opinião você ganharia algumas coisas:

  • Domínio mais expressivo - CRM e Nome comunicam melhor do que "String"
  • Validação encapsulada - CRM provavelmente tem um formato, poderia ser validado. Nome deve ter um tamanho máximo, ou uma exigência mínima de ter pelo menos um sobrenome.
  • Estender comportamento - Se a aplicação precisasse do primeiro nome para exibir após logar, poderia ser extraído do Nome, ao invés de fazer uma lógica em uma String. Outro exemplo é o CRM fornecer a informação de qual Estado ele é.
  • Formatação e Conversão - Os próprios Value Objects teriam essas capacidades, sem precisar recorrer às classes comuns que frequentemente encontramos como Utils ou Parsers, mais orientado a função (procedural) do que objetos.

Vi que isso tem até um nome técnico, "Obsessão por primitivos", e mesmo usando DDD, a gente tende a limitar o uso de nossos próprios tipos, que nos dão muito poder e expressividade, para não aumentar o número de classes.

Fica a reflexão.

1 resposta
solução!
por Lorena Garcia
| 10330.8k xp | 15421 posts
Alura Scuba Team

Oii, Reinaldo!

Muito boa a sua reflexão sobre o uso de Value Objects para atributos como CRM e Nome. O que você trouxe faz muito sentido e está em sintonia com práticas comuns em modelagem rica com DDD.

Ao encapsular campos como esses, você realmente ganha em expressividade do domínio, centralização de regras de validação e possibilidade de estender comportamentos com mais clareza, como obter o primeiro nome ou descobrir o estado a partir de um CRM, por exemplo.

E, mover essas responsabilidades para dentro dos objetos contribui para deixar o código mais organizado, reutilizável e testável, evitando o uso de classes utilitárias soltas no sistema.

Sobre a chamada “obsessão por primitivos”, é um ponto bem levantado. Abrir mão de um String direto para representar conceitos ricos como Nome, Email ou CPF é um passo que aproxima o código do negócio de forma clara e consistente.

Dica: esse tipo de abordagem também melhora a legibilidade e manutenção do sistema no longo prazo, mesmo que adicione mais classes ao projeto.

Alura Conte com o apoio da comunidade Alura na sua jornada. Abraços e bons estudos!