SkillProgramaçãoDiagnostica

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.

Em:Diagnóstico de Dívida Técnica CríticaPlanejamento de Refatoração e Arquitetura Alvo
Ações
PerfilDev
ProfundidadeAlta
IdiomaPortuguês
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
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
Execução

Como usar
com IA.

  1. 01Copie a skill (botão "Copiar skill para IA", no topo): o texto copiado já é a skill completa, não um resumo.
  2. 02Abra o Claude ou Claude Code e cole — a IA recebe todas as instruções e fica pronta para a tarefa.
  3. 03Prefere usar como arquivo reutilizável? Baixe o .zip e coloque o SKILL.md em .claude/skills/ (Claude Code) ou anexe o arquivo no Claude (claude.ai).