Framework e banco mudam a cada três a cinco anos. Regra de negócio dura décadas. Quando uma é refém da outra, cada migração de tecnologia vira projeto com escopo de reescrita. Sistema onde a lógica de cálculo de preço conhece o ORM específico, ou onde a regra de aprovação de crédito sabe em qual banco de dados está persistindo, tem custo de troca que cresce a cada sprint. Quando o fornecedor muda política de licenciamento, quando a tecnologia para de receber suporte de segurança, ou quando a arquitetura precisa escalar de uma forma que o banco atual não suporta, a empresa descobre que trocar uma peça exige mexer em tudo.
Subcapability 03 de 05 · Software Engineering & Architecture
Clean Architecture & Patterns
Clean Architecture com Dependency Rule que isola regras de negócio de frameworks, banco e UI, reduzindo custo de troca de tecnologia de projeto de seis meses para sprint.
O que está em jogo
O time quer trocar o banco de dados. Ou atualizar o framework para receber patches de segurança. Ou separar leitura de escrita para suportar o volume que o negócio atingiu. Em cada caso, a descoberta é a mesma: a regra de negócio está tão entrelaçada com a tecnologia específica que qualquer mudança de infraestrutura exige tocar no núcleo do sistema. O custo de troca sobe a cada sprint que passa sem separação de responsabilidades.
O que é, na prática
Como atuamos
Dependency Rule como princípio central
Estruturamos o código em camadas com dependências apontando sempre para dentro, em direção às regras de negócio. Entities e Use Cases não conhecem banco, framework ou UI. Cada camada externa depende da interna, nunca o contrário.
Ports and Adapters para substituição de tecnologia
Definimos portas que expressam o que a aplicação precisa da infraestrutura em termos de domínio, e adaptadores que implementam esses contratos com a tecnologia específica. Trocar banco ou framework significa trocar adaptador, sem tocar em regra de negócio.
CQRS onde leitura e escrita têm requisitos diferentes
Separamos o modelo de leitura do modelo de escrita quando os dois têm requisitos de performance, consistência ou escala distintos. A separação permite otimizar cada caminho de forma independente sem comprometer o outro.
Event Sourcing para auditabilidade completa
Implementamos Event Sourcing em domínios onde o histórico de mudanças de estado tem valor regulatório ou operacional. O estado atual é derivado da sequência de eventos. Replay de evento permite reconstruir qualquer estado passado com auditoria completa.
Teste de domínio sem dependência de infraestrutura
Estruturamos a camada de domínio para ser testável com testes unitários puros, sem banco em memória, sem mock de framework e sem container de integração. Feedback rápido na lógica que mais importa.
Ganhos mensuráveis
O que muda no resultado quando essa subcapacidade amadurece.
Custo de troca de tecnologia de infraestrutura
Regras de negócio isoladas na camada interna reduzem o escopo de impacto de cada mudança de banco, framework ou provedor externo ao adaptador correspondente. A troca que antes exigia projeto de meses passa a ser escopo de sprint.
Cobertura de teste em lógica de negócio crítica
Domínio sem dependência de infraestrutura permite testes unitários rápidos e determinísticos na lógica que mais importa para o resultado. Build que roda em minutos, não em horas de container de integração.
Tempo de entendimento de regra de negócio por engenheiro novo
Lógica de negócio concentrada na camada de domínio, sem entrelaçamento de preocupações de persistência ou apresentação, reduz o tempo para entender o que o sistema faz e onde cada mudança deve ser feita.
Impacto de atualização de framework em regras de negócio
Frameworks na camada externa como detalhe substituível significa que patches de segurança, atualizações de versão e trocas de fornecedor afetam apenas o adaptador. O núcleo do sistema permanece estável.
Perguntas frequentes
Clean Architecture, Hexagonal e Onion Architecture são a mesma coisa?
São variações do mesmo princípio central: dependências apontando para o domínio, infraestrutura na borda. Clean Architecture usa a metáfora de camadas concêntricas com Entities, Use Cases, Interface Adapters e Frameworks. Hexagonal Architecture usa a metáfora de portas e adaptadores. Onion Architecture usa as mesmas camadas com nomenclatura ligeiramente diferente. Na prática, o que define o resultado é a aplicação rigorosa da regra de dependência, não o nome que o time usa.
CQRS vale para qualquer sistema?
CQRS tem custo de complexidade. Para sistemas onde leitura e escrita têm os mesmos requisitos de performance e consistência, a separação adiciona indireção sem benefício real. O padrão justifica o investimento quando leitura e escrita têm modelos de dados diferentes, escala diferente ou consistência eventual aceitável na leitura. Esses cenários aparecem em sistemas de alto volume com requisitos distintos de query e de transação.
Event Sourcing resolve todos os problemas de auditabilidade?
Event Sourcing garante auditabilidade completa com capacidade de replay, mas tem custo operacional. O estado atual de uma entidade é calculado pela sequência de eventos, o que pode ser lento para entidades com histórico longo sem snapshots. A complexidade de query em sistemas de Event Sourcing puro exige projeções (read models) separadas. O padrão é o mais adequado para domínios onde o histórico tem valor intrínseco: financeiro, saúde, contratos.
Como migrar um sistema existente para Clean Architecture?
A abordagem mais segura começa pelos módulos com maior frequência de mudança ou maior risco de troca de tecnologia. Identify the Pain First. Para cada módulo, isole a lógica de negócio em uma camada interna sem dependência de infraestrutura. Crie adaptadores para banco, APIs externas e framework. Valide com testes unitários na camada de domínio. O Strangler Fig Pattern aplica essa migração incrementalmente, sem reescrita total e sem parar o sistema.
Como o time convence a empresa a investir em separação de arquitetural?
Com o custo do estado atual em linguagem econômica. Quanto tempo levou a última troca de tecnologia? Quantos bugs surgiram em regras de negócio durante a atualização de framework? Quanto do orçamento de engenharia foi para remediação de problemas causados pelo entrelaçamento de camadas? Esses números existem e tornam o investimento em separação de responsabilidades argumentável no board com retorno calculável.
Outras subcapabilities desta capability
Arquitetura Evolutiva
ADRs e fitness functions que registram decisões caras de reverter e validam conformidade automaticamente, mantendo o custo de cada mudança dentro de limites que o negócio consegue absorver.
Domain-Driven Design
Linguagem ubíqua e bounded contexts do Domain-Driven Design que alinham modelo de software ao modelo de negócio e eliminam a camada de tradução onde retrabalho e custo se acumulam.
Testing Strategy
Estratégia de testes calibrada por risco, custo e velocidade que substitui pirâmide invertida por distribuição que dá confiança real para mudar e elimina a cerimônia do medo.
Code Quality & Craft
Technical Debt Ratio mensurável e Quality Gates reais que mantêm velocidade de entrega sustentável e impedem que dívida técnica silenciosa vire congelamento de evolução.
Quer clareza sobre onde investir primeiro?
Diagnóstico completo de capacidades de tecnologia com roadmap de evolução conectado ao resultado financeiro.