DTO, DAO e Repository no Spring Boot
DTO, DAO e Repository: o que cada padrão resolve e por que não são sinônimos.
Por que isso é importante
DTO, DAO e Repository existem para separar transporte, persistência e domínio. Na era da IA isso importa mais: sem fronteiras, o gerador espalha ORM em todo canto.
O que são padrões arquiteturais?
Padrões arquiteturais são soluções reutilizáveis e testadas pra problemas que aparecem sempre no design de sistemas. No Spring Boot, eles ajudam a estruturar a aplicação de forma previsível, segura e que aguenta crescimento.
Arquitetura em camadas na prática
A estrutura em camadas segue essa ordem: Client → Controller → Service → Repository → Database. Cada camada tem uma responsabilidade só, bem definida, pra facilitar manutenção e evolução do sistema.
DTO: comunicando dados sem expor tudo
DTOs (Data Transfer Objects) são usados entre Client e Controller pra transportar só os dados relevantes, sem expor a estrutura completa do banco. Por exemplo, na criação de usuário, não precisa mandar o ID.
Atenção
Usar a Entity direto nas requisições pode expor dados sensíveis e estruturas internas que não precisam aparecer.
Entity: o espelho do banco de dados
A Entity representa direto uma tabela no banco. A classe UserEntity, por exemplo, espelha a tabela de usuários e tem todos os campos definidos nela, marcada com @Entity.
Transformações entre DTO e Entity
Precisa de um jeito de converter DTOs em Entities e vice-versa. Isso é feito pelos Mappers, que isolam essas conversões e ajudam a manter o projeto organizado e escalável.
Dica
Use bibliotecas como MapStruct pra automatizar a criação de Mappers no Spring Boot de forma segura e prática.
O papel do UserMapper
O UserMapper tem métodos como toDTO e toEntity, que convertem os objetos entre camadas. Isso garante que só os dados necessários circulem entre os módulos.
Repository: conexão limpa com o banco
A camada Repository substitui o antigo padrão DAO (Data Access Object). Com Spring Data JPA você usa só uma interface estendendo JpaRepository pra ter acesso aos métodos de leitura, escrita e consulta.
Fato importante
No Spring Data JPA, o Repository cobre o papel clássico do DAO com menos boilerplate: interface + convenções geram CRUD e consultas — ainda assim a fronteira com o domínio continua sua responsabilidade.
O que vai na camada Service?
Toda a lógica de negócio fica concentrada na camada Service. Validações como checar se um email já existe, transformar e salvar dados ou aplicar regras de autorização acontecem aqui.
Controller: porta de entrada da aplicação
Controllers expõem os endpoints que podem ser acessados externamente. Recebem dados pelos DTOs, delegam pros services e devolvem as respostas adequadas.
Erro comum
Não coloca regras de negócio no controller. Ele só coordena entrada e saída de dados.
Resumo do fluxo completo
Ferramentas que facilitam seu trabalho
Checklist de Implementação
Perguntas frequentes
Qual a diferença entre DTO e Entity?
Entity/model representa o domínio/persistência; DTO é contrato de transporte (API/UI). Misturar os dois vaza detalhes de banco para a borda.
DAO e Repository são a mesma coisa?
Parecidos na intenção (acesso a dados). Repository costuma falar a língua do domínio; DAO fica mais perto da tabela/SQL. No dia a dia o nome importa menos que a fronteira clara.
Preciso de todas as camadas num MVP?
Não. Comece simples; introduza DTO/Repository quando o acoplamento do controller ao ORM começar a doer.
Isso ainda vale na era da IA?
Sim. IA gera código rápido; sem fronteiras você gera acoplamento rápido. Camadas claras facilitam review e troca de ORM.