REST API para gerenciamento de tarefas, reescrita em arquitetura de camadas — routes, controllers, services e repository — com Prisma sobre PostgreSQL, validação Zod, testes automatizados, Docker e CI.
A primeira versão da API misturava validação, regra de negócio e acesso a dados na mesma camada — funcional, mas difícil de testar isoladamente e arriscado de evoluir. O desafio era reescrever a API inteira numa arquitetura que permitisse testar a regra de negócio sem banco de dados, e trocar de ORM ou banco no futuro sem tocar na lógica central.
A API segue routes → controllers → services → repository, com uma regra simples: apenas o `task.repository.ts` importa `@prisma/client`. O `TaskService` concentra toda a regra de negócio e é testado isoladamente com o repository mockado, sem precisar de banco nos testes unitários. A validação de entrada usa Zod em um middleware genérico (`validate()`), o logging é estruturado com Pino, e erros HTTP passam por um `errorHandler` centralizado que formata a resposta de forma consistente. Helmet e rate limiting cobrem um hardening básico de produção.
Único ponto de acesso ao banco isolado no repository, com migrations versionadas e um client singleton lazy.
Validação de entrada e variáveis de ambiente, com tipos inferidos diretamente do schema — falha rápido se algo estiver errado.
29 testes — unitários mockando o repository inteiro, e de integração validando o fluxo completo contra um Postgres real.
Build otimizado em múltiplos estágios, com docker-compose subindo API e Postgres juntos para desenvolvimento local.
Hardening básico de produção — cabeçalhos de segurança HTTP e limitação de requisições por IP.
CI completo a cada push — lint, type-check, testes com Postgres em serviço, e build, antes de qualquer merge.
O Task Manager API demonstra que arquitetura em camadas bem definida não é exclusividade de sistemas grandes — mesmo um domínio simples como tarefas se beneficia de uma separação clara entre regra de negócio e infraestrutura. A regra de negócio é testável sem banco, o erro HTTP é sempre consistente, e trocar Postgres por outro banco no futuro não exigiria tocar no `TaskService`. README documenta inclusive as limitações conhecidas — sem autenticação, sem soft-delete — como próximos passos explícitos, não como falhas escondidas.