Arquitetura em 3 camadas:a IA escrevendo código limpo

A IA gera código bagunçado porque o seu projeto não tem arquitetura, não porque a IA é ruim. Uma arquitetura em 3 camadas resolve isso. Dê a ela três camadas claras — componentes para a UI, serviços para a lógica de negócio, uma camada de dados para o banco — e faça prompts de uma camada por vez, e a mesma IA produz código limpo, testável e escalável. Foi assim que construí o FIKR Space.

Aqui está o padrão, por que ele funciona e a sequência exata de prompts.

O problema: IA sem estrutura cria caos

Você pede à IA para construir uma funcionalidade. Ela te entrega código. Você cola. Uma semana depois, a sua base de código é uma bagunça: chamadas ao banco de dados espalhadas por todo lado, lógica de negócio misturada com a UI, código copiado e colado em todo canto, impossível de testar, quebra quando você tenta escalar.

A IA não é o problema. A sua arquitetura é.

A IA gera o que você pede. Mas, sem uma arquitetura clara, ela mistura responsabilidades, cria padrões inconsistentes e não consegue manter a estrutura da sua base de código — cada prompt cria um caos novo. A IA não conhece a sua arquitetura. Você precisa guiá-la.

A solução: uma arquitetura em 3 camadas

Imagine o seu app como um prédio de três andares. Componentes no topo — só UI. Serviços no meio — lógica de negócio. A camada de dados embaixo — banco de dados e APIs. Cada andar só conversa com o que está logo abaixo dele. Quando a IA sabe em que camada está trabalhando, ela gera código limpo.

• Camada 1 — Componentes (só UI). O que pertence aqui: lógica de exibição, interações do usuário, roteamento, layout. O que não pertence: chamadas ao banco de dados, lógica de negócio, validação, permissões. Um componente ruim busca usuários no banco de dados dentro de si mesmo, filtrando por status no caminho. Um componente bom pede a um hook os "usuários ativos", mostra um esqueleto de carregamento enquanto espera e renderiza a lista. Esse é o trabalho inteiro.
• Camada 2 — Serviços (lógica de negócio). O que pertence aqui: busca de dados, validação, permissões, regras de negócio, transformação de dados. O que não pertence: qualquer coisa que renderize, ou estado específico de componente. Um UserService conhece as regras — uma organização é obrigatória, quais filtros se aplicam, o que acontece em caso de falha — e é o único lugar onde essas regras vivem.
• Camada 3 — Dados (banco de dados e APIs). Consultas ao banco, chamadas de API, integrações externas. Acessada só pelos serviços, nunca direto pelos componentes.

Como fazer prompts para a IA com esse padrão

O jeito errado é um único prompt: "Construa uma funcionalidade de gestão de usuários." O resultado é tudo num componente só — chamadas ao banco, validação, UI, tudo misturado. O jeito certo são três prompts, de baixo para cima, uma camada cada:

1. Primeiro o serviço: "Gere um UserService com métodos para buscar, criar, atualizar e excluir usuários. Inclua validação e tratamento de erros."
2. Depois o hook: "Crie um hook useUsers que envolva o UserService com cache."
3. Por último o componente: "Construa um componente UserList que use o hook useUsers. Exiba estados de carregamento e trate erros."

Resultado: código limpo e separado, cada camada focada na sua responsabilidade. Pedir tudo de uma vez é o erro número um — a IA gera código misturado, com todas as camadas embaralhadas. Uma camada por vez, construindo de baixo para cima.

O livroA Revolução do EUpreendedorLuis Gonçalves sobre como construir um negócio de EUpreendedor com IA sem largar o emprego.Quero o livro →

Funciona com qualquer stack

Mesmo padrão, ferramentas diferentes:

Já tem código bagunçado? A migração em 5 passos

1. Encontre todas as chamadas ao banco de dados. Procure nos seus componentes chamadas diretas ao banco e a APIs.
2. Crie serviços. Mova todo o acesso a dados para classes de serviço — a consulta que vivia dentro de um componente agora vive num método de serviço com tratamento de erros.
3. Crie hooks. Envolva cada serviço com a camada de busca de dados do seu framework, para que os componentes ganhem cache e estados de carregamento de graça.
4. Atualize os componentes. Substitua o padrão de buscar dados dentro do componente por uma única chamada de hook.
5. Deixe a IA ajudar. Prompt: "Refatore este componente para usar o padrão de hook. Mova a lógica de banco de dados para um serviço." A IA migra cada parte.

O retorno aparece na hora nos testes: serviços são testados sem nenhuma UI, hooks são testados como camadas finas, e componentes são testados com o hook simulado. Camadas limpas = testes fáceis.

Por que isso funciona

Sem camadas, a IA gera componentes monolíticos, duplica lógica entre arquivos e produz código difícil de testar, difícil de manter e que quebra ao escalar. Com camadas, a IA gera código focado para cada camada, a lógica fica centralizada nos serviços, cada camada é testada de forma independente — e o padrão escala para bases de código enormes.

Eu construí assim. Funciona. Essa é exatamente a arquitetura por trás do FIKR Space: 5 produtos integrados, construídos com o Claude, rodando em produção. Os dois erros a evitar: pular os serviços ("vou usar os hooks direto com o banco de dados" — lógica de negócio em hooks é difícil de testar e impossível de reutilizar) e componentes inchados ("vou colocar a validação nos componentes" — você não consegue reutilizá-la nem testá-la sem a UI).

Antes de publicar, rode o checklist: nenhum import de banco de dados nos componentes, toda a lógica de negócio nos serviços, componentes cuidando só da UI, hooks envolvendo serviços, serviços testáveis sem UI, tratamento de erros em todas as camadas. Esse padrão é o pilar 2 de os cinco pilares do software de produção — e, uma vez que as camadas existem, prompts estruturados como o método PRP ficam muito mais confiáveis, porque cada prompt tem um lugar óbvio.

12 semanasA sua carreira corporativa nunca foi o planoCandidate-se à Aceleradora de EUpreendedores.Candidatar-se →

Perguntas frequentes

Preciso entender de código para usar a arquitetura em 3 camadas?

Você precisa entender o mapa, não as ruas. Saber que UI, lógica de negócio e acesso a dados são três andares separados — e que cada prompt mira exatamente um deles — basta para direcionar a IA corretamente. A arquitetura é uma ferramenta de comunicação entre você e a IA, e direcionar é a sua metade do trabalho.

3 camadas não é exagero para um MVP pequeno?

Não, porque o custo é quase zero e a alternativa se acumula. Três prompts em vez de um no primeiro dia são minutos de trabalho extra; desembaraçar chamadas ao banco de dados de cinquenta componentes no sexto mês são semanas. O padrão funciona desde um projeto de fim de semana até uma plataforma inteira em produção — já o usei nas duas pontas.

O que vai num serviço e o que vai num hook?

As regras vão no serviço; o encanamento vai no hook. Se é uma decisão de negócio — o que conta como válido, quem tem permissão, como um valor é calculado — pertence ao serviço. Se é sobre entregar dados para a tela — cache, flags de carregamento, nova busca — pertence ao hook. Na dúvida, coloque no serviço: serviços são mais fáceis de testar e reutilizar.

Como faço a IA respeitar as camadas automaticamente?

Declare a regra nas instruções permanentes do seu projeto: componentes nunca importam o cliente do banco de dados, todo acesso a dados passa pelos serviços, hooks envolvem serviços. Depois faça cada prompt nomear a sua camada ("crie um método de serviço para…"). A IA segue a arquitetura que está de fato escrita — nunca a que está na sua cabeça.