Agendar não é guardar data

Agendar entrega de fornecedor é uma daquelas operações que todo mundo resolve em planilha até o dia em que dá errado. Dois fornecedores no mesmo horário, um funcionário que não está disponível, e nenhum histórico de quem marcou o quê. Quando fui escrever a API, a parte fácil era o banco: uma tabela de compromissos resolve o armazenamento. A parte que decidia o projeto era outra — dizer "não" na hora certa.

Onde a regra mora

A API é em Go com Gin e GORM sobre PostgreSQL, autenticação por JWT e controle de acesso por papel. A verificação de disponibilidade e a detecção de conflito acontecem na camada de regra, antes de qualquer escrita. O handler não decide nada sozinho — ele traduz HTTP para uma chamada de domínio e devolve a resposta.

Essa escolha é o motivo de o projeto estar separado em api/handlers, api/middleware, api/routes, models e repository. Não é cerimônia por cerimônia: é o que permite testar e mudar a regra de conflito sem tocar na rota, e é onde a maior parte dos bugs de agendamento costuma nascer. O mesmo vale para o resto do domínio — disponibilidade, produto, operação, recorrência e notificação moram em modelos próprios, mesmo quando ainda não são o caminho principal.

O que eu levaria a sério no próximo passo

O repositório não tem testes. É a primeira coisa que eu consertaria: uma regra de conflito sem teste é uma regra que ninguém sabe se ainda vale depois da terceira alteração. Ficou de fora também qualquer autenticação de terceiros — JWT simples resolve o caso, e provedor externo seria complexidade antes de necessidade.

Em compensação, cuidei do que diz respeito a quem vai consumir a API: Dockerfile e docker-compose para subir com banco, Makefile para os atalhos, hot reload com Air durante o desenvolvimento e uma collection do Postman versionada no repositório — porque documentação que vive fora do código envelhece sozinha.

A API está publicada, com autenticação, disponibilidade, conflito e relatórios funcionando: Scheduling API.