Um dos livros que mais marcaram o mundo da arquitetura de software é Patterns of Enterprise Application Architecture, do Martin Fowler.
É um clássico, denso, cheio de conceitos e discussões sobre como construir sistemas corporativos robustos e de longo prazo.
Mas hoje quero conversar sobre ele de forma leve, como um papo de corredor entre quem gosta de engenharia e boas práticas.
Meu objetivo é traduzir o conceito de Layering (Camadas) de um jeito acessível e aplicável no dia a dia.
Afinal, entender o por que é tão importante quanto entender o como.
Layering (Camadas) na Arquitetura de Software
Por que falar de camadas?
Sempre que alguém diz “minha camada de negócio” ou “a camada de dados”, está aplicando um dos princípios mais antigos da arquitetura de software: a separação de responsabilidades.
Dividir o sistema em partes bem definidas faz com que ele fique:
- mais fácil de entender,
- mais simples de dar manutenção,
- e menos propenso a virar aquele famoso macarrãozão de código.
Exemplo prático, Pense num e-commerce. Você pode ter:
- Camada de apresentação (UI): mostra os produtos e recebe os cliques do usuário.
- Camada de negócio (domain/service): valida regras, como estoque disponível e cálculo de frete.
- Camada de dados (repository): fala com o banco, buscando e salvando informações.
Separar isso faz toda diferença. Se amanhã você quiser mudar o banco de dados de MySQL para MongoDB, não precisa mexer nas regras de negócio. Cada parte cuida do seu papel.
Abstração: a chave de uma boa arquitetura
Camadas funcionam porque existe abstração entre elas. Uma camada não precisa saber como a outra funciona, só o que ela faz.
Exemplo prático
Imagine que você tem um UserService que chama um UserRepository.
O serviço não precisa saber se os dados vêm de um banco SQL, de um arquivo JSON ou de uma API externa, ele apenas chama algo como userRepository.findById(id).
// Service
const user = await userRepository.findById(id)
return user.activate()// Repository
findById(id) {
return database.query('SELECT * FROM users WHERE id = ?', [id])
}Essa abstração permite trocar o repositório sem mexer na camada de negócio. Mas vale lembrar: abstrair demais também é perigoso.
Já vi projetos com 10 camadas intermediárias entre o controller e o banco.
- Camadas demais viram um labirinto.
- Camadas de menos viram um caos acoplado.
- O segredo está no equilíbrio.
Layer vs Tier: a confusão clássica
É muito comum confundir Layer com Tier, mas eles são coisas diferentes.
- Layer (Camada): separação lógica no código.
Exemplo: controller, service, repository. - Tier: separação física na infraestrutura.
Exemplo: front-end em um servidor, backend em outro, banco em um terceiro.
Exemplo prático
Um sistema pode ter três layers (Controller → Service → Repository)
mas rodar em apenas um tier (um único servidor).
Já outro sistema pode ter as mesmas camadas, só que divididas fisicamente:
- O front-end React hospedado na Vercel,
- O backend Node em um servidor AWS,
- E o banco PostgreSQL em outro tier.
Resumindo:
Camada = organização do código.
Tier = organização da infraestrutura.
Pasta não é camada
Outro erro super comum é achar que separar arquivos em pastas significa que o código está em camadas.
Não está.
Exemplo prático
Ter algo assim:
/controllers
/services
/repositoriesnão garante que exista separação de responsabilidades.
Se o seu controller faz validação, acessa banco e envia e-mail, as pastas não serviram pra nada.
Camada é sobre o comportamento do código, não sobre onde ele está salvo.
Você pode ter um único arquivo com separações claras — e isso ainda é layering.
Conclusão: camadas são sobre clareza e longevidade
Entender a diferença entre separação lógica (layer) e física (tier) é essencial para construir sistemas que duram.
Camadas bem definidas ajudam você a:
🔧 Manter e evoluir código com segurança
🧠 Raciocinar sobre a arquitetura com clareza
🚀 Escalar sistemas sem perder o controle
Pense nas camadas como o esqueleto de uma boa aplicação.
Elas sustentam o corpo, dão forma e garantem que cada parte funcione sem atrapalhar a outra.
No fim das contas, fazer arquitetura é cuidar do seu código como quem cultiva um jardim: aparando excessos, separando o que precisa de espaço e garantindo que tudo cresça em harmonia.