O que é arquitetura de software?
Que raio é isso? O que isso faz? Vamos começar com algumas definições de caras que sabem o que estão falando.
Robert Martin (Uncle Bob) diz o seguinte:
The goal of software architecture is to minimize the human resources required to build and maintain the required system.
Ou seja, o objetivo da arquitetura de software é minimizar os recursos humanos necessários para construir e manter um sistema.
Já Martin Fowler define assim:
Software architecture is those decisions which are both important and hard to change.
Ou seja, a arquitetura de software são as decisões importantes e difíceis de mudar.
Agora, bora descomplicar: arquitetura de software tem a ver com organização, estrutura, design, relacionamento e comportamento.
Se você já escreveu um software do zero ou participou da reescrita de um sistema legado, sabe do que estou falando. O chefe deu carta branca, escolheu-se tecnologia, servidores, frameworks… tudo isso são decisões arquiteturais. E, adivinha? Elas vão te acompanhar enquanto o sistema estiver no ar.
Essas decisões são afetadas por fatores como:
- O escopo do produto
- O orçamento da empresa (quanto tem para equipe, servidores, etc.)
- O volume de requisições
- O nível técnico da equipe (sênior, pleno, júnior, estagiários…)
- O prazo de entrega
Agora, pense comigo: se a empresa tem meia dúzia de clientes, faz sentido criar um sistema distribuído com Kafka, Kubernetes e banco replicado? Ou será que seria um gasto desnecessário?
Cada tipo de software exige uma arquitetura diferente. Um ERP não é um jogo de RPG online, uma plataforma de streaming não é um simples CLI. Existem várias arquiteturas: monolítica, distribuída, cliente-servidor, orientada a eventos, serverless... e cada uma resolve um problema específico.
E só porque você usou Clean Architecture em um projeto, não significa que precisa replicar isso em todos os outros. Se você tem um sistema que só cadastra um e-mail numa newsletter, faz sentido implementar Clean Architecture, Hexagonal Architecture ou MVC? Não.
O que é Clean Architecture?
Clean Architecture é um modelo arquitetural focado em desacoplar as regras de negócio dos recursos externos (como banco de dados, frameworks, etc.).
Exemplo: seu ORM deve ficar isolado na camada dele, fazendo apenas operações de banco (salvar, atualizar, deletar). Enquanto isso, a entidade do ORM (que representa uma tabela) não deve ser a mesma entidade que contém as regras de negócio.
Como surgiu a Clean Architecture?
O próprio Uncle Bob criou esse conceito enquanto desenvolvia um software junto com o filho dele. Era um sistema onde os usuários criavam testes baseados em uma wiki.
Durante o projeto, ele percebeu que quando olhava para a estrutura de pastas, só via Rails. Ele não queria ver Rails, queria enxergar o propósito da aplicação. O problema? O sistema estava totalmente dependente do framework.
Então, ele começou a separar as regras de negócio das dependências externas, focando no core da aplicação e nos testes.
Foi daí que surgiu a ideia: o centro da aplicação não é o banco de dados e nem o framework. O centro da aplicação são os casos de uso.
Use Cases: O Coração da Aplicação
Uncle Bob definiu assim:
The center of your application is not the database, nor is it one or more of the frameworks you may be using. The center of your application is the use cases of your application.
Ou seja, o centro da sua aplicação são os casos de uso.
Se liga: quando você projeta um sistema, qual a primeira coisa que a maioria das empresas pensa? No banco de dados. "Qual vai ser a tabela?", "Quais colunas precisa ter?"
Esse pensamento está invertido. O certo seria definir os casos de uso primeiro.
Casos de uso são as intenções do usuário dentro do sistema. Exemplo:
- Fazer check-in
- Adicionar itens ao carrinho
- Processar um pagamento
Esses casos de uso contêm as regras de negócio e chamam as entidades para resolver as operações.
E se, ao escrever um caso de uso, você percebe que ele depende de uma regra contida em outro caso de uso? A resposta é não reutilizar casos de uso diretamente. Se isso aconteceu, significa que você identificou uma regra de negócio independente e que ela deve estar na camada de entidades.
Entities: O Núcleo das Regras de Negócio
Aqui entram as regras de negócio puras, que podem ser aplicadas em diferentes contextos.
E aqui está um erro comum: confundir entidade de regra de negócio com entidade de ORM.
A entidade do ORM mapeia o banco de dados (ex: mapeamento de colunas para atributos). Já a entidade da Clean Architecture representa um conceito de negócio, independente do banco.
O que acontece se você misturar as duas coisas?
Se adicionar decorators, annotations ou outras dependências do ORM dentro da sua entidade de regra de negócio, você cria alto acoplamento. Resultado? Uma simples mudança na tabela do banco pode quebrar as regras de negócio.
Entidades precisam ser independentes. Elas podem ser classes ou simplesmente um conjunto de funções puras. A forma depende do seu estilo de código e do time.
Interface Adapters: A Ponte Entre Mundo Externo e Casos de Uso
Essa camada traduz os dados entre o mundo externo e a lógica de negócio.
Aqui entra toda a arquitetura MVC: controllers, middlewares, presenters...
O fluxo é assim:
- O usuário faz uma requisição.
- O dado chega na camada de Interface Adapters, que adapta e joga dentro de um DTO.
- O DTO vai para o caso de uso, que processa tudo e retorna um resultado.
- A resposta é adaptada novamente e enviada para o usuário.
Essa camada não deve conhecer detalhes como banco de dados, mensageria, etc.
Frameworks and Drivers: O Mundo Externo
Essa é a camada mais externa. Aqui entram:
- Banco de dados
- Redis
- Nginx
- Kafka
- Qualquer outra dependência externa
A ideia é manter esses componentes isolados, evitando que impactem a lógica de negócio.
Conclusão
Não confunda camadas lógicas com pastas no projeto. Você pode jogar todos os arquivos na raiz e ainda assim manter as camadas organizadas. O que define as camadas é a dependência:
- O que está fora pode depender do que está dentro.
- O que está dentro nunca pode depender do que está fora.
Vantagens da Clean Architecture
✔ Isolamento das regras de negócio
✔ Definição clara de camadas e responsabilidades
✔ Fluxo de dependência ordenado e direcional
✔ Facilidade para testar
✔ Independência de frameworks e banco de dados
✔ Facilidade para evolução tecnológica
Top comments (0)