TenantCore

Visão geral

Sistema fullstack para operação de um SaaS B2B multi-tenant. O domínio central é a gestão de workspaces empresariais compartilhados por múltiplas empresas, com isolamento por tenant, controle de usuários e perfis, cadastro de clientes, projetos e tarefas, assinatura por plano, limites de uso e auditoria.

O problema resolvido não é apenas CRUD: o sistema simula um backend corporativo em que várias empresas usam a mesma plataforma sem vazar dados entre si, mantendo segurança, governança e visibilidade operacional.

Arquitetura

Monólito modular com Clean Architecture dentro de um monorepo fullstack. A escolha entrega complexidade enterprise sem o custo operacional de uma malha de serviços.

• TenantCore.Api Borda HTTP: controllers, middlewares, auth, rate limit, health checks e Swagger.
• TenantCore.Application Casos de uso, handlers do MediatR, validação com FluentValidation e contratos.
• TenantCore.Domain Entidades com comportamento (UpdateSettings, ChangeRole, ChangePlan, Rotate) e enums.
• TenantCore.Infrastructure EF Core, SQL Server, Redis, Quartz, JWT, password hashing e observabilidade.

Fluxo de autenticação e isolamento por tenant

1. O usuário informa email, senha e TenantId na tela de login.
2. O frontend envia o header X-Tenant-Id junto das credenciais para /api/auth/login.
3. O middleware valida o tenant, busca o usuário dentro do tenant correto e valida a senha.
4. O handler gera access token JWT e refresh token, salva o hash do refresh token no banco e grava auditoria de login.
5. Em toda requisição seguinte, o middleware compara o header X-Tenant-Id com o claim tenantId do token.
6. O TenantCoreDbContext aplica query filters globais por TenantId — consultas normais não conseguem enxergar dados de outro tenant.
7. Operações de escrita checam permissão por papel, validam limites do plano, gravam AuditLog e invalidam caches como usage:{tenantId}.
8. Jobs Quartz atualizam snapshots de uso, recalculam o estado de cota e limpam tokens expirados.

Pontos fortes

• Multi-tenancy com defesa em profundidade: middleware, claims do token e query filters do EF Core.
• JWT com refresh token rotativo e revogação, acima da média de projetos júnior.
• RBAC real por papel (Admin/Manager/User) com enforcement no backend.
• CQRS pragmático: MediatR para comandos e queries, e um read model com Dapper para o dashboard agregado.
• Observabilidade com Serilog, OpenTelemetry, health checks e Jaeger local.
• CI/CD e deploy real na Azure, com documentação de arquitetura, segurança, runbook e ADRs.

Limites e decisões conscientes

O que este projeto não faz, e por quê. Descrever isso com precisão vale mais do que exagerar o escopo.

• Não há arquitetura orientada a eventos: sem broker, filas, consumidores, outbox ou sagas. O que existe é trilha de auditoria e processamento agendado.
• O DDD é parcial — as entidades têm comportamento, mas não há value objects, domain events, aggregate roots explícitos ou bounded contexts formais.
• É um monólito modular, não microservices: uma única API e um único banco relacional.
• O README principal menciona Neon PostgreSQL, mas o código atual está acoplado a SQL Server.