Clean Architecture: quando a organização do código é decisão de negócio

O problema que Clean Architecture resolve

Quando regras de negócio estão misturadas com código de banco de dados, framework web e chamadas HTTP, qualquer mudança tecnológica exige refatoração extensiva das regras de negócio. Trocar de banco de dados requer entender a lógica de negócio. Testar as regras de negócio requer subir toda a infraestrutura.

O princípio central: dependência apontando para dentro

Clean Architecture organiza o sistema em camadas concêntricas: entidades de negócio no centro, casos de uso em volta, adaptadores na borda e infraestrutura na camada mais externa. A regra fundamental: dependências só podem apontar para dentro. Infraestrutura conhece os casos de uso. Casos de uso não conhecem a infraestrutura.

O impacto de negócio

• Testabilidade — regras de negócio testáveis sem banco de dados, sem servidor web, sem dependências externas.
• Flexibilidade tecnológica — trocar o banco de dados não toca as regras de negócio.
• Velocidade de mudança — quando o negócio muda uma regra, o código muda em um único lugar.

O trade-off honesto

Clean Architecture tem custo de adoção: mais arquivos, mais camadas de abstração, curva de aprendizado. Para sistemas simples e de vida curta, o custo pode não se pagar. Para sistemas que crescem e mudam por anos, o investimento retorna multiplicado.