# Visão Geral da Arquitetura

Este documento resume a arquitetura **com base apenas no código** presente no repositório.

## Componentes principais (evidência no código)

### Camada HTTP (rotas, controllers e middleware)

- Rotas web: `routes/web.php`
- Rotas API: `routes/api.php`
- Middleware (inclui multi-tenancy e MFA):
  - `app/Http/Middleware/Tenant.php`
  - `app/Http/Middleware/VerifiedMFA.php`
  - `app/Http/Middleware/RedirectIfAuthenticated.php`
- Kernel de middleware:
  - `app/Http/Kernel.php` (grupos `web` e `api`)

### Camada de domínio/persistência (Eloquent)

- Model base da persistência multi-tenant:
  - `app/Models/TenantModel.php` (fixa a connection `tenant`)
- Model base da persistência “central” (não multi-tenant):
  - `app/Models/MainModel.php` (fixa `mysql`)

### Camada de services / integrações

Há uma pasta `app/Services/` com serviços por domínio, por exemplo:

- Mensageria: `app/Services/Message/*`
- Webhooks: `app/Services/Webhook/*`
- RabbitMQ: `app/Services/RabbitMQ/*`
- Bot/fluxos: `app/Services/Bot/*`
- Relatórios: `app/Services/Relatorio/*`

### Repositories

Há `app/Repositories/` (por exemplo RabbitMQ):

- `app/Repositories/RabbitMQ/MessageRepository.php`

## Estratégia de multi-tenancy (alto nível)

O tenant é resolvido em runtime via middleware `Tenant`, que:

1. Identifica o tenant (por `token_whatsapp` no request ou por `Auth()->user()->cliente_id`).
2. Resolve um registro em `App\Models\Cliente` e chama `connect()`.
3. `connect()` ajusta dinamicamente a conexão Laravel chamada `tenant` (host/database/credenciais), e então reconecta.

Evidências:

- Identificação no middleware: `app/Http/Middleware/Tenant.php`
- Troca de conexão no `connect()`:
  - `app/Models/Cliente/Cliente.php`
- A conexão do Eloquent tenant fica amarrada em:
  - `app/Models/TenantModel.php`

## Exemplo de fluxo HTTP (request -> response) encontrado no código

Um fluxo “real” no repositório é o relatório de atendimento consumido pelo front-end:

1. O front-end carrega `resources/views/atendimento/relatorio.blade.php`, que inclui o script:
   - `public/pages/scripts/relatorioatendimento/initrelatorio.js`
2. O script usa DataTables em serverSide e faz `POST` para `/atendimento/query` (com CSRF):
   - Evidência em `initrelatorio.js` (uso de `url: "/atendimento/query"` e payloads)
3. A rota correspondente está em `routes/web.php`:
   - `Route::post('atendimento/query', 'Atendimento\AtendimentoController@relatorio')->middleware(\App\Http\Middleware\Tenant::class);`
4. O controller `Atendimento\AtendimentoController@relatorio` monta query/resultado e responde no formato usado pelo DataTables.

Observação: a montagem detalhada da resposta depende do controller específico; neste projeto, há uso de query pesada no controller e/ou helper de relatório.

## Limitações deste documento

- Não identificado no código: global scopes automáticos (`GlobalScope`, `addGlobalScope`, etc.) no nível de Model.
- Não identificado no código: uma “arquitetura em camadas” formal (ex.: Clean Architecture) com contratos/interfaces por camada; a organização existe, mas não há evidência de regras formais além de pastas/namespaces.