Aferente e Eferente | Livro - Fundamentos de Arquitetura de Software
- Aferente e Eferente | Livro - Fundamentos de Arquitetura de Software
Acoplamento Aferente e Eferente em Arquitetura de Software
Os conceitos de acoplamento aferente e eferente são métricas estruturais introduzidas por Robert C. Martin (Uncle Bob) e amplamente discutidas em Clean Architecture.
Eles medem dependências entre módulos, pacotes ou componentes, sendo fundamentais para avaliar estabilidade arquitetural.
Definições Formais
Acoplamento Aferente (Ca)
Quantidade de módulos externos que dependem de um determinado módulo.
Em termos simples:
Quantos componentes apontam para mim?
Representa responsabilidade e estabilidade.
Se muitos módulos dependem de um módulo X, X tende a ser mais estável e menos sujeito a mudanças.
Acoplamento Eferente (Ce)
Quantidade de módulos dos quais um determinado módulo depende.
Em termos simples:
De quantos componentes eu dependo?
Representa dependência externa e instabilidade potencial.
Visualização Conceitual
Considere três módulos:
[ API ] ---> [ Application ] ---> [ Domain ]
Domain
- Ca = 1 (Application depende dele)
- Ce = 0 (não depende de ninguém)
Application
- Ca = 1 (API depende dele)
- Ce = 1 (depende de Domain)
API
- Ca = 0
- Ce = 1 (depende de Application)
Interpretação Arquitetural
Alto Acoplamento Aferente (Ca alto)
Indica:
- Módulo central
- Alta responsabilidade
- Alta estabilidade esperada
- Alto custo de mudança
Exemplo típico:
- Camada de domínio
- Biblioteca compartilhada
Alto Acoplamento Eferente (Ce alto)
Indica:
- Forte dependência externa
- Maior fragilidade
- Maior probabilidade de quebra por mudanças externas
Exemplo típico:
- Camada de infraestrutura
- Módulo de integração com terceiros
Instabilidade (I)
Robert C. Martin define a métrica de instabilidade:
I = Ce / (Ca + Ce)
Valores possíveis:
- 0 → completamente estável
- 1 → completamente instável
Interpretação
| I | Interpretação |
|---|---|
| 0 | Muito estável |
| 0.5 | Balanceado |
| 1 | Muito instável |
Exemplo em C#
Estrutura
Projeto.Domain
Projeto.Application
Projeto.Infrastructure
Projeto.Api
Dependências típicas
- Application → Domain
- Infrastructure → Domain
- Api → Application
Análise
Domain
- Ca = 2 (Application + Infrastructure)
- Ce = 0
- I = 0 / 2 = 0 (altamente estável)
Infrastructure
- Ca = 0
- Ce = 1 (Domain)
- I = 1 / 1 = 1 (instável)
Isso é desejável.
Camadas internas devem ser mais estáveis que externas.
Relação com a Regra da Dependência
Na Clean Architecture:
Dependências devem apontar para dentro.
Ou seja:
- Camadas externas dependem das internas
- Nunca o contrário
Isso reduz acoplamento e aumenta independência de evolução.
Relação com Conascência
- Conascência mede tipo e qualidade da dependência
- Aferente/Eferente mede quantidade da dependência
Ambos são complementares.
Exemplo:
Um módulo pode ter:
- Baixo Ce (poucas dependências)
- Mas alta conascência de algoritmo (dependência forte e perigosa)
Heurística Prática
Perguntas úteis:
- Este módulo é dependido por muitos outros? → Avaliar estabilidade.
- Ele depende de muitos outros? → Avaliar fragilidade.
- A direção das dependências respeita a arquitetura definida?
- A camada mais interna possui Ce > 0? Se sim, há violação estrutural.
Resumo Estrutural
| Métrica | Mede | Alto valor significa |
|---|---|---|
| Ca | Quem depende de mim | Estabilidade |
| Ce | De quem eu dependo | Instabilidade |
| I | Proporção de dependência | Nível de instabilidade |