SkillEngenhariaEstruturação

Desenho de Arquitetura Alvo para Refatoração

Define a arquitetura ideal para o módulo refatorado, com fronteiras claras, responsabilidades isoladas e padrões desejados.

Em:Planejamento de Refatoração e Arquitetura Alvo
Ações
PerfilDev
ProfundidadeAlta
Idiomapt-BR
Objetivo

Em uma frase.

Definir claramente o estado final desejado (target architecture) para o módulo a ser refatorado, garantindo que o esforço resolva as dores estruturais diagnosticadas e forneça uma direção coesa, antes de iniciar o planejamento de fatiamento.

Aplicação

Quando
faz sentido.

Usar
  • Como Etapa 1 do workflow de Planejamento de Refatoração e Arquitetura Alvo.
  • Logo após um diagnóstico completo de dívida técnica, quando o problema é conhecido, mas a solução estrutural ainda não foi desenhada.
  • Quando o time quer aplicar um novo paradigma arquitetural (ex: migração para microserviços, adotar arquitetura hexagonal) a um módulo legado.
Não usar
  • Sem ter um diagnóstico claro dos problemas atuais — a arquitetura alvo deve curar as dores mapeadas, não apenas aplicar design patterns por estética.
  • Em tarefas pequenas que não alteram a estrutura de pastas, acoplamento ou contratos gerais do sistema.
Prompt

Instruções
para a IA.

Passo 1 — Extrair Requisitos Estruturais do Diagnóstico

A arquitetura alvo não nasce no vácuo. Analise o diagnóstico técnico prévio para elencar os objetivos não-funcionais que a refatoração deve alcançar:

- Onde o acoplamento estava alto e precisa ser quebrado. - Onde a testabilidade é ruim e necessita de injeção de dependência ou isolamento I/O. - Hotspots complexos que carecem de delegação de responsabilidades.

Passo 2 — Definir Paradigmas e Padrões Aplicáveis

Com base na stack e no ecossistema da equipe, defina qual padrão arquitetural melhor resolve as dores estruturais mapeadas:

- Arquitetura de Camadas Clássica - Arquitetura Hexagonal (Ports & Adapters) - Vertical Slice Architecture - CQRS simplificado

Aponte claramente por que o padrão escolhido resolve ativamente os problemas de instabilidade e acoplamento definidos no diagnóstico anterior.

Passo 3 — Desenhar Fronteiras de Responsabilidade (Context Boundaries)

Refinar os componentes do módulo, demarcando as caixas estritas do sistema alvo:

- **Core Domain:** As regras essenciais de negócio. Deve ser agnóstico à infraestrutura externa. - **Interfaces e Adaptadores:** Como o sistema se comunica externamente (Controllers, Listeners, Repositories). - **Contratos:** Quais interfaces (interfaces de código) irão conectar o Core com os Adaptadores para garantir baixo nível de acoplamento temporal/espacial.

Passo 4 — Mapear Tratamento de Invariantes de Negócio

Garanta que as invariantes de negócio listadas no *Registro de Riscos* encontrem uma "casa" na nova arquitetura. Especifique com precisão ONDE na nova estrutura de pacotes ou pastas as regras vitais do sistema estarão encapsuladas e trancadas.

### Passo 5 — Documentar a Arquitetura Alvo

Descreva a arquitetura alvo através de:

- **Diagrama em formato C4 ou similar** (texto ou imagem). - **Estrutura sugerida:** Como os diretórios refletirão a arquitetura (ex: qual a aparência da ramificação de arquivos e módulos do código-fonte para refletir os contextos). - **Lista de heurísticas arquiteturais:** "Nenhum código no pacote Domain pode importar nada dos pacotes Database ou Web".

---
Constelação

Onde
ela vive.

Workflows que usam
Bundles que incluem