O que aprendi quando minha API começou a ficar maior que o CRUD 🚀

Quando comecei a desenvolver minha API REST com Java e Spring Boot, minha preocupação inicial era bem simples:

fazer o CRUD funcionar.

Criar um produto, buscar pelo ID, atualizar, excluir...

E no começo isso realmente parecia ser a maior parte do trabalho.

Só que, conforme o projeto foi crescendo, comecei a perceber que o CRUD era apenas o começo.

Quando começam a aparecer os problemas reais

Depois de adicionar relacionamentos entre entidades, regras de negócio e persistência com PostgreSQL, algumas decisões que pareciam pequenas começaram a fazer diferença.

Por exemplo:

• O que acontece quando tento cadastrar algo que já existe?
• O que a API deve retornar quando um recurso não é encontrado?
• Como lidar com filtros diferentes sem transformar o Repository em uma lista enorme de métodos?
• O que acontece se uma operação precisar alterar várias informações e uma delas falhar?
• Como testar essas regras sem depender do banco de dados?

Foi aí que comecei a entender melhor conceitos como Specifications, DTOs, exceções, @Transactional e testes automatizados.

Um exemplo que me chamou atenção

Em uma busca por ID, simplesmente deixar uma exceção escapar pode fazer uma situação esperada pelo sistema virar um:

500 Internal Server Error

Mas se o recurso não existe, isso não significa necessariamente que a aplicação quebrou.

Pode ser simplesmente um:

404 Not Found

Essa diferença parece pequena, mas muda bastante a forma como o cliente da API consegue interpretar o que aconteceu.

Foi quando comecei a enxergar o tratamento de exceções não apenas como uma forma de "evitar erros", mas como parte do contrato da API.

E os filtros?

Outra coisa interessante aconteceu quando comecei a adicionar filtros.

No início, era fácil imaginar métodos como:

findByNome(...)
findByCategoria(...)
findByPreco(...)

Mas e quando o usuário pudesse combinar vários filtros?

Nome + categoria + preço mínimo + preço máximo...

Foi nesse momento que comecei a estudar Spring Data JPA Specifications.

Em vez de criar um método diferente para cada combinação possível, a ideia passa a ser construir os critérios de consulta de forma dinâmica.

Isso me fez perceber uma coisa:

conforme a aplicação cresce, o problema deixa de ser apenas "como fazer funcionar?" e passa a ser "como fazer continuar funcionando sem tornar tudo difícil de manter?"

O CRUD continua sendo importante

Não acho que aprender CRUD seja algo ruim.

Pelo contrário.

Ele foi justamente o ponto de partida para eu conseguir chegar nesses problemas.

A diferença é que, depois de algum tempo praticando, comecei a perceber que uma aplicação real envolve muito mais do que:

Controller → Service → Repository

Também precisamos pensar em:

regras de negócio → consistência → erros → testes → manutenção → evolução

E cada uma dessas partes começa a aparecer naturalmente conforme o projeto cresce.

O que mais mudou minha forma de estudar

Talvez a maior mudança tenha sido parar de enxergar cada tecnologia como um assunto isolado.

Java me levou ao Spring.

Spring me levou ao JPA e ao banco de dados.

Os problemas do projeto me levaram a estudar testes, transações e arquitetura.

E, mais recentemente, comecei a conectar esse conhecimento com IA e agentes, pensando em como construir aplicações que realmente utilizem essas tecnologias para resolver problemas.

Ainda estou aprendendo bastante coisa, mas hoje tento olhar para cada problema do projeto como uma oportunidade de descobrir por que determinada ferramenta existe, em vez de apenas aprender como utilizá-la.

No fim, acho que essa foi uma das principais coisas que meu projeto de supermercado me ensinou:

Um projeto começa como um exercício de programação, mas pode acabar se tornando um exercício de engenharia de software.

E provavelmente ainda tenho muito mais para descobrir conforme ele continuar crescendo. 😅

Para quem também está desenvolvendo um projeto pessoal: em que momento vocês perceberam que o projeto estava deixando de ser apenas um CRUD e começando a exigir decisões de arquitetura e engenharia?