Onde colocar as validações? O dilema entre DTO, Service e Entidade

Se você já desenvolveu uma API, certamente parou diante do teclado com uma dúvida cruel: "Onde eu coloco essa validação?".

Devo usar as anotações do Bean Validation no DTO? Devo verificar se o usuário existe dentro do Service? Ou será que a regra de negócio deveria estar protegida dentro da Entidade?

Vamos explorar como organizar sua casa (ou melhor, seu código) para que cada camada cumpra o seu papel sem gerar uma bagunça de responsabilidades.

1. O DTO: O Porteiro do seu Sistema

O DTO (Data Transfer Object) é a primeira linha de defesa. Ele representa os dados que vêm de fora (do frontend ou de outra API) para dentro do seu sistema.

O que validar aqui: O foco é puramente técnico e estrutural. Formatos de e-mail, se um campo obrigatório está presente, o tamanho mínimo de uma senha ou se um valor numérico está dentro de um intervalo aceitável.

O insight: O DTO não conhece as regras do seu negócio. Ele apenas garante que o dado é "aceitável" para cruzar a fronteira da aplicação. Se o JSON está malformado ou falta um campo essencial, o sistema nem deve perder tempo processando.

2. A Camada de Service: O Maestro

No ecossistema Java/Spring/Quarkus, o Service costuma ser o coração da aplicação, mas ele tem uma função específica: orquestração.

O que validar aqui: Aqui moram as validações que dependem de infraestrutura. Exemplo: "Este e-mail já está cadastrado no banco de dados?" ou "Este cliente tem saldo suficiente para esta transação?.

A realidade do mercado: Embora muitos defendam o DDD (Domain-Driven Design) puro, assim como "Modelo Anêmico" (entidades com apenas getters e setters) é muito comum no mercado. Nesses casos, o Service acaba herdando quase toda a lógica de negócio por necessidade técnica.

3. Entidades: A Alma do Negócio

Em uma arquitetura ideal, a Entidade deveria ser "rica". Ela deve garantir a integridade do domínio independentemente de quem a chama.

O insight: Se você tem uma regra que diz que "um pedido não pode ser criado sem pelo menos um item", essa lógica deveria estar dentro da classe "Pedido", e não espalhada em múltiplos Services.

Isso evita que o sistema entre em estados inválidos por erro de um desenvolvedor que esqueceu de chamar uma validação no Service.

4. E o Banco de Dados?

Para quem trabalha com sistemas legados ou grandes ERPs, as validações no banco (via constraints, triggers ou procedures) são uma realidade. Embora o desenvolvimento moderno tente manter a lógica no código para facilitar testes, o banco de dados é a última linha de defesa para garantir a integridade dos dados.

Considerações finais

O pragmatismo vence o purismo.

A grande lição que tiramos dessa discussão é que contexto é rei.

Se você trabalha em uma empresa que segue padrões rígidos de Service, não tente ser o "rebelde do DDD" sozinho. O código precisa ser legível e sustentável para a equipe. O segredo é ter camadas:

1. DTO valida a forma.
2. Service orquestra a lógica e consulta o mundo externo.
3. Entidade protege as regras fundamentais do negócio.

Quanto mais camadas de validação você tiver (de forma organizada), mais seguro e resiliente será o seu software.

Feito!