SkillEngenhariaDiagnostica
Mapeamento de Dependências e Decomposição
Mapeia componentes, endpoints, serviços e integrações de um módulo para revelar acoplamento e fronteiras reais.
Ações
PerfilDev
ProfundidadeAlta
Idiomapt-BR
Objetivo
Em uma frase.
Produzir um mapa completo de dependências de um módulo ou subsistema — identificando componentes internos, dependências externas, consumidores, fluxos de dados e pontos de acoplamento — para que decisões de refatoração sejam baseadas na topologia real do código e não em suposições.
Aplicação
Quando
faz sentido.
Usar
- Como Etapa 2 do workflow de Diagnóstico de Dívida Técnica Crítica, após a coleta de contexto de negócio.
- Como Etapa 2 do workflow de Planejamento de Refatoração, para gap analysis entre estado atual e arquitetura alvo.
- Quando um módulo precisa ser modificado mas ninguém no time sabe o alcance real das dependências.
- Quando há medo de "efeito dominó" — mudar uma coisa e quebrar outras.
- Antes de qualquer refatoração que envolva mover código entre módulos, extrair serviços ou mudar contratos de API.
Não usar
- Para análise de complexidade interna de funções — use cyclomatic-complexity-audit.
- Para avaliar riscos de negócio — use risk-register-and-guardrails.
- Quando o módulo é completamente isolado e sem consumidores (raro mas possível).
Prompt
Instruções
para a IA.
Passo 1 — Inventariar os componentes internos do módulo
Listar todos os componentes que vivem dentro do módulo alvo:
- **Arquivos e classes principais:** Quais são os arquivos de entrada? Quantos arquivos compõem o módulo?
- **Responsabilidades declaradas:** O que cada componente principal faz (ou tenta fazer)?
- **Componentes "Deus":** Há arquivos com mais de 500 linhas ou classes com mais de 10 métodos públicos? Estes são candidatos imediatos a decomposição.
- **Padrões observados:** O módulo segue algum padrão arquitetural (MVC, hexagonal, camadas)? Ou é ad-hoc?Produzir uma lista de componentes com: nome, responsabilidade declarada, tamanho (linhas) e número de dependências diretas.
Passo 2 — Mapear dependências de saída (o que o módulo usa)
Para cada componente interno, identificar tudo de que ele depende:
- **Imports diretos:** Bibliotecas, frameworks, módulos internos de outros domínios.
- **Chamadas a serviços:** APIs REST, gRPC, GraphQL, mensageria (Kafka, SQS, etc.).
- **Acesso a dados:** Queries diretas a banco, ORM, cache (Redis, Memcached).
- **Integrações externas:** SDKs de terceiros, webhooks, serviços cloud.Para cada dependência, classificar: - **Estável:** Não muda frequentemente, API bem definida. - **Volátil:** Muda com frequência, contrato instável. - **Tóxica:** Acoplamento tão forte que impede mudanças no módulo.
Passo 3 — Mapear dependências de entrada (quem usa o módulo)
Identificar todos os consumidores do módulo:
- **Chamadores internos:** Quais outros módulos, controllers ou serviços chamam funções deste módulo?
- **API pública:** Se o módulo expõe endpoints, quem os consome? (frontend, mobile, outros serviços, parceiros)
- **Eventos publicados:** O módulo emite eventos que outros consomem?
- **Dados compartilhados:** Outros módulos leem diretamente tabelas ou caches que este módulo gerencia?Para cada consumidor, documentar: o que ele consome, volume estimado e criticidade (se parar de funcionar, quem é afetado?).
Passo 4 — Traçar fluxos de dados críticos
Para os fluxos de negócio identificados na ficha de contexto, traçar o caminho dos dados pelo módulo:
- De onde vem o dado (request, evento, cron)?
- Quais transformações sofre dentro do módulo?
- Para onde vai (banco, outro serviço, response)?
- Onde estão os pontos de falha (timeout, serialização, validação)?Produzir um diagrama ou lista sequencial para os 3 fluxos mais críticos.
Passo 5 — Identificar pontos de acoplamento problemáticos
Com base nos passos anteriores, identificar onde o acoplamento impede mudanças seguras:
- **Acoplamento temporal:** Dois componentes precisam executar numa ordem específica não garantida por contrato.
- **Acoplamento de dados:** Componentes compartilham estruturas de dados internas em vez de contratos estáveis.
- **Acoplamento de implantação:** Mudar um componente exige deploy de outro componente junto.
- **Dependências circulares:** A depende de B que depende de A.
- **God object compartilhado:** Múltiplos consumidores dependem de um objeto monolítico que mistura responsabilidades.Para cada ponto de acoplamento: descrever o que acopla, por que é problemático e qual seria a fronteira ideal.
Passo 6 — Produzir mapa consolidado
Consolidar o inventário em um documento estruturado:
```
## Mapa de Dependências — [Nome do Módulo]Componentes Internos
| Componente | Responsabilidade | Linhas | Deps diretas | Classificação | |------------|-----------------|--------|--------------|---------------| | ... | ... | ... | ... | ... |Dependências de Saída
| Dependência | Tipo | Estabilidade | Impacto se indisponível | |-------------|------|-------------|------------------------| | ... | ... | ... | ... |Consumidores (Dependências de Entrada)
| Consumidor | O que consome | Volume | Criticidade | |------------|--------------|--------|-------------| | ... | ... | ... | ... |Fluxos Críticos
[Diagrama ou lista sequencial dos top 3 fluxos]Pontos de Acoplamento
| Ponto | Tipo | Componentes envolvidos | Severidade | |-------|------|----------------------|------------| | ... | ... | ... | ... | ```---
Constelação
Onde
ela vive.
Workflows que usam
Bundles que incluem