Arquitetura é o conjunto de decisões difíceis de reverter. Quando essas decisões não são registradas, a empresa herda a arquitetura por acidente. Cada feature nova paga juros sobre escolhas que ninguém lembra de ter feito. O acoplamento cresce silenciosamente. A fronteira entre módulos some. O que era sistema estruturado vira massa de código que ninguém ousa tocar sem medo de derrubar outra coisa.
Subcapability 01 de 05 · Software Engineering & Architecture
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.
O que está em jogo
A arquitetura foi decidida, mas não documentada. Cada developer novo interpreta o padrão de forma diferente. Cada exceção se torna a nova norma. Quando a empresa tenta escalar, o sistema revela que as decisões que pareciam locais têm consequências globais. O custo de cada mudança sobe porque o acoplamento cresceu sem que ninguém tenha declarado essa dívida.
O que é, na prática
Como atuamos
Architecture Decision Records ativos
Documentamos cada decisão arquitetural significativa com contexto, alternativas consideradas, trade-offs aceitos e data de validade esperada. O ADR acompanha o código no repositório e é revisado quando as condições que o justificavam mudam.
Fitness functions no pipeline
Implementamos verificações automatizadas de conformidade arquitetural que rodam a cada commit: limites de acoplamento entre módulos, proibição de dependências circulares e restrições de camada. Violação é capturada antes da revisão manual, quando o custo de correção é mínimo.
Escolha de padrão por problema
Avaliamos monolito modular, microservices e event-driven com critério explícito por contexto: volume de times, necessidade de deployment independente, requisitos de consistência e capacidade operacional. O padrão certo para o problema certo, sem adoção por tendência de conferência.
Mapeamento de dívida arquitetural
Tornamos visível o passivo acumulado com inventário de decisões que divergiram do padrão, custo estimado de remediação por item e impacto em lead time de mudança. Dívida declarada tem plano. Dívida oculta cresce sem endereço.
Governança arquitetural contínua
Estabelecemos processo de revisão arquitetural para mudanças significativas, com critério explícito do que exige review formal e o que segue padrão estabelecido. Governança que não trava velocidade e que mantém coerência do sistema ao longo do tempo.
Ganhos mensuráveis
O que muda no resultado quando essa subcapacidade amadurece.
Lead time para mudança arquitetural significativa
Fitness functions que detectam erosão precocemente e ADRs que documentam o raciocínio original reduzem o tempo para identificar o ponto de mudança e avaliar o impacto. O que levava semanas de análise passa a ter referência documentada e validação automatizada.
Percentual de violações arquiteturais detectadas antes do merge
Fitness functions no pipeline movem a descoberta de violação de camada, acoplamento e dependência circular para o momento do commit. O custo de correção nesse ponto é uma fração do custo em produção ou em sistema com acoplamento já estabelecido.
Tempo de onboarding de engenheiro em novo sistema
ADRs ativos eliminam o período de tradição oral onde o engenheiro novo aprende o que não deve fazer por tentativa e erro. O raciocínio arquitetural está no repositório, acessível desde o primeiro dia.
Custo de troca de tecnologia de borda
Arquitetura com fronteiras explícitas e dependências documentadas reduz o escopo de impacto de cada mudança de tecnologia periférica. A troca de banco, framework ou provedor afeta a camada de adaptador, não o núcleo de regras de negócio.
Perguntas frequentes
O que diferencia ADR de documento de arquitetura tradicional?
Documento de arquitetura descreve o sistema como ele é. ADR registra por que uma decisão foi tomada, quais alternativas foram descartadas e em que condições a decisão deve ser revisitada. Quando o contexto muda, o ADR é o ponto de partida para avaliar se a decisão original ainda é válida. Documento que só descreve o estado atual fica obsoleto sem aviso.
O que é fitness function e por que automatiza governança arquitetural?
Fitness function é um teste que verifica uma propriedade arquitetural desejada de forma automatizada. Pode ser um teste que falha quando um módulo importa de módulo errado, quando a complexidade ciclomática supera um limiar ou quando um serviço introduz dependência síncrona onde o padrão exige assíncrono. O que antes dependia de revisão manual e atenção do arquiteto passa a ser verificado em cada commit.
Quando monolito modular é preferível a microservices?
Monolito modular é preferível quando o time ainda está descobrindo os bounded contexts corretos, quando o volume de tráfego não justifica a complexidade operacional de múltiplos serviços ou quando a organização não tem capacidade de operar pipelines independentes por serviço. Microservices trazem custo operacional real. A opção por eles antes de ter esse custo coberto pelo ganho de deployment independente gera o pior dos dois mundos: complexidade de distribuído com acoplamento de monolito.
Como medir dívida arquitetural em termos econômicos?
Dívida arquitetural tem custo em lead time: quanto tempo a mais cada mudança leva por causa do acoplamento existente. Ferramentas como SonarQube, Structure101 e análise de dependências via Maven ou Gradle permitem quantificar dependências circulares, violações de camada e métricas de coesão. O custo de remediação de cada item, estimado em dias de engenharia, torna o passivo legível no board.
Com que frequência ADRs devem ser revisados?
ADRs devem ser revisados quando a condição que os motivou muda. Volume de tráfego que ultrapassa o que o modelo atual suporta, mudança de requisito de compliance, adoção de tecnologia que altera o trade-off original. A data de revisão esperada deve ser parte do ADR. ADR sem revisão prevista é documento que envelhece sem percepção.
Outras subcapabilities desta capability
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.
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.
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.