Modelagem de Domínio

Quando Usar

Use quando este fluxo de trabalho corresponder à solicitação do usuário: Construir e refinar o modelo de domínio de um projeto. Use quando o usuário quiser definir a terminologia do domínio ou uma linguagem ubíqua, registrar uma decisão arquitetural ou quando outra habilidade precisar manter o modelo de domínio.

Fonte: mattpocock/skills (MIT).

Construa e refine ativamente o modelo de domínio do projeto durante o design. Esta é a disciplina ativa — desafiando termos, inventando cenários de casos extremos e escrevendo o glossário e as decisões no momento em que se cristalizam. (Apenas ler CONTEXT.md para vocabulário não é esta habilidade — esse é um hábito de uma linha que qualquer habilidade pode fazer. Esta habilidade é para quando você está mudando o modelo, não apenas consumindo-o.)

Estrutura de Arquivos

A maioria dos repositórios tem um único contexto:

/
├── CONTEXT.md
├── docs/
│   └── adr/
│       ├── 0001-event-sourced-orders.md
│       └── 0002-postgres-for-write-model.md
└── src/

Se um CONTEXT-MAP.md existir na raiz, o repositório tem múltiplos contextos. O mapa aponta para onde cada um vive:

/
├── CONTEXT-MAP.md
├── docs/
│   └── adr/                          ← system-wide decisions
├── src/
│   ├── ordering/
│   │   ├── CONTEXT.md
│   │   └── docs/adr/                 ← context-specific decisions
│   └── billing/
│       ├── CONTEXT.md
│       └── docs/adr/

Crie arquivos de forma preguiçosa — apenas quando tiver algo para escrever. Se nenhum CONTEXT.md existir, crie um quando o primeiro termo for resolvido. Se nenhum docs/adr/ existir, crie-o quando o primeiro ADR for necessário.

Durante a Sessão

Desafiar o Glossário

Quando o usuário usar um termo que conflita com a linguagem existente em CONTEXT.md, chame a atenção imediatamente. "Seu glossário define 'cancelamento' como X, mas você parece querer dizer Y — qual é?"

Refinar Linguagem Vaga

Quando o usuário usar termos vagos ou sobrecarregados, proponha um termo canônico preciso. "Você está dizendo 'conta' — você quer dizer o Cliente ou o Usuário? Essas são coisas diferentes."

Discutir Cenários Concretos

Quando as relações de domínio estiverem sendo discutidas, teste-as com cenários específicos. Invente cenários que explorem casos extremos e forcem o usuário a ser preciso sobre os limites entre os conceitos.

Cruzar Referências com o Código

Quando o usuário declarar como algo funciona, verifique se o código concorda. Se encontrar uma contradição, aponte-a: "Seu código cancela Pedidos inteiros, mas você acabou de dizer que o cancelamento parcial é possível — qual está certo?"

Atualizar CONTEXT.md Inline

Quando um termo for resolvido, atualize CONTEXT.md ali mesmo. Não agrupe essas atualizações — capture-as conforme acontecem. Use o formato em CONTEXT-FORMAT.md.

CONTEXT.md deve ser totalmente desprovido de detalhes de implementação. Não trate CONTEXT.md como uma especificação, um bloco de rascunho ou um repositório de decisões de implementação. É um glossário e nada mais.

Oferecer ADRs com Moderação

Ofereça-se para criar um ADR apenas quando todas as três condições forem verdadeiras:

1. Difícil de Reverter — o custo de mudar de ideia depois é significativo
2. Surpreendente sem Contexto — um leitor futuro se perguntará "por que eles fizeram isso dessa maneira?"
3. Resultado de um Trade-off Real — havia alternativas genuínas e você escolheu uma por razões específicas

Se alguma das três estiver faltando, pule o ADR. Use o formato em ADR-FORMAT.md.

Limitações

• Requer a ferramenta upstream, conta, chave de API ou configuração local quando o fluxo de trabalho nomeia uma.
• Não autoriza ações destrutivas, de produção, pagas ou de mensagens externas sem aprovação explícita do usuário.
• Valide artefatos ou recomendações geradas contra as fontes reais do usuário antes de tratá-las como finais.