Pular para o conteúdo principal
Versão: main (dev) 🚧

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çãoPor 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.