ADR-001 — Vertical slices as canonical layout (non-negotiable)

Date: 2026-05-07 Status: Accepted Pareado com: TODO TEMPLATE-B-01

Context

Sessões A/B/C de Fase 2 hesitaram entre três estruturas de pasta para a camada Application:

1. Vertical slices por feature — Application/Orders/CreateOrder/{Command,Handler,Validator,Response}.cs.
2. PT-BR vertical — Application/Pedidos/CriarPedido/... (mesma estrutura, identifiers em PT).
3. Split por tipo — Application/Commands/CreateOrder/... ao lado de Application/Queries/GetOrderById/....

Outras pastas alternativas consideradas: Application/UseCases/, Application/Features/, Application/Slices/. Todas equivalentes na prática.

Decision

Vertical slices por feature, com Application/{Module}/{Feature}/ é canon e não-negociável. Empacotamento dotnet new mantém Orders literal (não placeholder substituível): consumidor imita por exemplo, não substitui por scaffold.

Estrutura concreta:

Application/{Module}/
├── {Feature}/
│   ├── {Verb}{Entity}Command.cs          (or Query)
│   ├── {Verb}{Entity}Handler.cs
│   ├── {Verb}{Entity}Validator.cs        (when input has field-level rules)
│   └── {Verb}{Entity}Response.cs         (only if not shared)
├── Events/                                ← INotificationHandler<T> per domain event
└── {Entity}Mappings.cs                    (manual extension methods or Mapperly)

Consequences

Positivas:

• Coesão por mudança: quem mexe em "criar order" toca 3-4 arquivos vizinhos, não 3 pastas distantes.
• Cohabitação Command + Validator + Handler torna trivial achar tudo no IDE: Application/Orders/CreateOrder/ é a unidade mental.
• Onboarding rápido: padrão repetido por feature é aprendido uma vez.

Negativas:

• "Pastas por feature" cria muitos diretórios pequenos — pode parecer fragmentado em projetos com poucas features no início.
• Refatorações cross-feature (mudar comportamento de validação compartilhado, por exemplo) tocam várias pastas em paralelo.

Anti-padrão rejeitado:

• Split por tipo (Commands/ vs Queries/) é proibido. A divisão visual destrói a coesão por mudança sem benefício compensatório — ninguém procura "todos os queries", procura "tudo de Orders".

Alternatives considered

Opção	Por que descartada
Split por tipo (Commands/Queries)	Destrói coesão.
Application/Features/Orders/CreateOrder/	Acréscimo Features/ é redundante; Application/Orders/ já comunica "feature".
Estrutura PT (Pedidos, CriarPedido)	Substituída pelo English-only (ADR-002).

References

• CLAUDE.md § Feature folders (canonical layout) — vertical slices, NÃO-NEGOCIÁVEL.
• docs/todos/2026-05-07-todos-decisoes-pre-fase-3-template.md § TODO TEMPLATE-B-01.