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

O que vem pronto

Tudo abaixo funciona no scaffold recém-gerado, sem configuração adicional além do Getting Started.

Vertical slices (canon Orders)​

Casos de uso moram em pastas únicas Application/{Modulo}/{Feature}/ — Command/Query, Handler, Validator e Response juntos, não divididos por tipo. A feature Orders (CreateOrder, ApproveOrder, GetOrderById, ListOrders) é a referência viva: para criar uma feature nova, replique a estrutura por imitação. O racional está no ADR-001.

Handlers retornam ValueTask<Result<T>> (Result pattern do DevPack Core); validação field-level vive em AbstractValidator<TCommand> e roda no pipeline antes do handler; invariantes de domínio vivem em métodos da entidade.

Autenticação dual-scheme (local, out-of-the-box)​

O template nasce com ASP.NET Core Identity local + dois schemes coexistindo (ADR-006):

  • Browser → cookie de sessão HttpOnly+Secure+SameSite (BFF) — zero token no JavaScript, CSRF via X-XSRF-TOKEN.
  • Mobile / service-to-service → Bearer JWT assimétrico (RSA), validado contra o JWKS publicado pela própria API; client-credentials para S2S.

Os dois desembocam em ICurrentUser, então a autorização downstream não muda entre schemes. Endpoints e payloads na seção API › Autenticação. Para quem já tem IdP corporativo, o swap para resource server externo é documentado em Extensibilidade.

Autorização role-based com permissões em banco​

Permissões seguem naming {Feature}.{Operation} (Orders.Create), declaradas em endpoint via RequireAuthorization(...). O mapeamento role → permissão é persistido na tabela RolePermissions (seed com Admin/Operator/Viewer) e resolvido com cache de 5 minutos — ADR-004.

Persistência EF Core + interceptors​

AuditedEntity com AuditTimestamp (UTC + timezone IANA), soft-delete e dispatch de domain events pós-save — tudo via interceptors do DevPack Infrastructure.EfCore, registrados com o builder fluente AddDevPackEfCoreInterceptors().

Frontend SPA same-origin​

React + Vite + TypeScript + Tailwind v4 + shadcn/ui, servido pela API (ADR-007) — é o que faz o cookie BFF funcionar sem CORS. Vertical slices também no front (features/{nome}/ com api.ts, access.ts, páginas), client HTTP tipado gerado do OpenAPI (openapi-fetch), testes com Vitest + Testing Library + MSW.

Operacional​

  • Observabilidade: OpenTelemetry (traces, métricas, runtime) com exporter OTLP configurado pelas env vars padrão (OTEL_EXPORTER_OTLP_ENDPOINT etc.).
  • Rate limiting: fixed-window global por IP (RateLimiting:PermitLimit/WindowSeconds), probes de health isentos.
  • API versioning: Asp.Versioning.Http com URL segment (/v1/...) + header fallback X-Api-Version.
  • CORS: desligado por default (same-origin); liga apenas quando Cors:AllowedOrigins é populado.
  • Concorrência otimista: RowVersion nos aggregates com transição de estado.

Testes​

Domain tests (xUnit) + integration tests end-to-end com WebApplicationFactoryBase do DevPack.Testing — InMemory provider, auth fake por header X-Test-Roles (CreateClientWithRoles("Admin")) e seed de usuário + service client para os testes de fluxo real de autenticação.