CRUD matou inovação. Não em 2024. Ele foi assassinado há dez anos.
Se você ainda escreve controllers REST que simplesmente mapeiam Create → POST, Read → GET, Update → PUT, Delete → DELETE, você está construindo interfaces, não APIs.
Uma interface faz o óbvio. Uma API faz o que ninguém esperava que fosse possível.
O Problema com CRUD
CRUD é o FastFood das APIs. Rápido de fazer, satisfaz a fome imediata, e deixa um vazio duas horas depois.
O padrão funciona enquanto sua aplicação é simples:
- Um usuário edita um post
- Um produto sai do estoque
- Uma transação é registrada
Mas na vida real? Negócios são caóticos. Um usuário edita um post, mas:
- Precisa validar contra permissões de grupo
- Dispara um workflow de aprovação
- Envia notificações para colaboradores
- Atualiza um índice de busca
- Registra auditoria
- Recomputa analytics
De repente, seu endpoint POST /posts/:id não faz mais um Update simples. Virou um coordenador de orquestração. E aquele método update() do seu controller? Virou 1000 linhas de lógica procedural que ninguém consegue testar isoladamente.
Isso é o CRUD Hell: você começou construindo entidades, terminou construindo monstos.
A Morte Começou com Eventos
Domain-Driven Design trouxe uma ideia revolucionária: em vez de pensar em operações (Create, Read, Update, Delete), pense em eventos que acontecem no seu domínio.
Um usuário não “Atualiza um post”. Um usuário dispara o evento “PostEdited” — e esse evento pode ter efeitos colaterais: notificações, auditorias, recompute de trends.
De repente, você tem Command Query Responsibility Segregation (CQRS) e Event Sourcing como práticas reais.