Arquitetura
Camadas, módulos e o ciclo de vida de uma requisição na Profile Server API.
A API segue uma organização Clean Architecture / DDD-lite, separando
domain (regras de negócio) de infra (HTTP, banco, cache, ambiente).
Camadas
core— utilitários transversais: o tipoEither(usado pelos use-cases para retornarLeft/Rightem vez de lançar exceções), entidades base e erros de domínio.domain— cada subdomínio (auth,user,tenancy,logger) contémapplication(use-cases, repositórios, decorators) eenterprise(entidades).infra— adapta o domínio ao mundo externo: controllers HTTP, Prisma, Redis e validação de ambiente.
Módulos NestJS
O AppModule monta os middlewares de autenticação e registra o
PermissionGuard globalmente via APP_GUARD.
Ciclo de vida de uma requisição
O trajeto de um request em /api/* passa por middleware de autenticação,
guard de permissão, pipe de validação (Zod), use-case e presenter.
Padrão dos controllers
Cada operação HTTP é um controller dedicado (um arquivo por caso de uso:
create-user, fetch-users, edit-user, ...). Padrões recorrentes:
- Validação —
ZodValidationPipecom um schema Zod declarado no próprio arquivo; o mesmo schema alimenta o Swagger viazodToSwaggerSchema. - Autorização — decorator
@Permissions(Resource, Scope). - Auditoria — decorator
@AuditLog(action, entity)em operações de escrita. - Saída — um
Presenter(UserPresenter,TenantPresenter, ...) converte a entidade de domínio no formato HTTP. - Erros de domínio — o use-case devolve
Either; o controller traduzLeftem exceções HTTP (ex.:ConflictException).