# 🏗️ Arquitetura: Employees vs Users

## 📋 **Visão Geral**

O sistema foi corrigido para separar claramente as responsabilidades entre **Employees** e **Users**, eliminando redundâncias e confusões.

## 🔄 **Mudanças Implementadas**

### ❌ **ANTES (Problemático):**
```sql
-- Tabela employees com campo role duplicado
CREATE TABLE employees (
    employee_id SERIAL PRIMARY KEY,
    employee_name VARCHAR(200) NOT NULL,
    username VARCHAR(50) UNIQUE NOT NULL,
    password VARCHAR(255) NOT NULL,
    role VARCHAR(20) DEFAULT 'employee',  -- ❌ DUPLICADO!
    -- outros campos...
);
```

### ✅ **DEPOIS (Corrigido):**
```sql
-- Tabela employees sem role
CREATE TABLE employees (
    employee_id SERIAL PRIMARY KEY,
    employee_name VARCHAR(200) NOT NULL,
    username VARCHAR(50) UNIQUE NOT NULL,
    password VARCHAR(255) NOT NULL,
    user_id INTEGER REFERENCES users(user_id),  -- ✅ RELACIONAMENTO!
    -- outros campos...
);
```

## 🎯 **Separação de Responsabilidades**

### 👥 **Tabela `users` (Autenticação & Autorização)**
```sql
CREATE TABLE users (
    user_id SERIAL PRIMARY KEY,
    username VARCHAR(50) UNIQUE NOT NULL,
    password VARCHAR(255) NOT NULL,
    role VARCHAR(20) NOT NULL,           -- ✅ ÚNICO SISTEMA DE ROLES
    permissions JSONB,                   -- ✅ PERMISSÕES ESPECÍFICAS
    is_active BOOLEAN DEFAULT true,
    last_login TIMESTAMP,
    created_at TIMESTAMP DEFAULT NOW()
);
```

**Responsabilidades:**
- ✅ **Login e autenticação**
- ✅ **Controle de acesso**
- ✅ **Permissões do sistema**
- ✅ **Sessões de usuário**

### 👷 **Tabela `employees` (Recursos Humanos)**
```sql
CREATE TABLE employees (
    employee_id SERIAL PRIMARY KEY,
    employee_name VARCHAR(200) NOT NULL,
    employee_code VARCHAR(50) UNIQUE NOT NULL,
    position_id INTEGER REFERENCES positions(position_id),
    salary DECIMAL(10,2),
    hire_date DATE,
    email VARCHAR(100) UNIQUE,
    phone VARCHAR(20),
    address TEXT,
    id_number VARCHAR(50) UNIQUE,
    tax_number VARCHAR(50) UNIQUE,
    bank_account VARCHAR(100),
    bank_name VARCHAR(100),
    emergency_contact VARCHAR(200),
    emergency_phone VARCHAR(20),
    status VARCHAR(20) DEFAULT 'Active',
    username VARCHAR(50) UNIQUE NOT NULL,  -- Para login interno
    password VARCHAR(255) NOT NULL,        -- Para login interno
    user_id INTEGER REFERENCES users(user_id), -- Relacionamento opcional
    created_at TIMESTAMP DEFAULT NOW(),
    updated_at TIMESTAMP DEFAULT NOW()
);
```

**Responsabilidades:**
- ✅ **Dados pessoais e profissionais**
- ✅ **Folha de pagamento**
- ✅ **Estrutura organizacional**
- ✅ **Informações de contato**
- ✅ **Dados bancários**

## 🔗 **Relacionamento entre Tabelas**

### **Cenário 1: Employee com User (Recomendado)**
```json
{
    "employee": {
        "employee_id": 1,
        "employee_name": "João Silva",
        "employee_code": "EMP001",
        "position_id": 1,
        "salary": 25000,
        "username": "joao.silva",
        "user_id": 5  // Relacionamento com users
    },
    "user": {
        "user_id": 5,
        "username": "joao.silva",
        "role": "manager",
        "permissions": {
            "loans": ["create", "read", "update", "approve"],
            "customers": ["create", "read", "update"],
            "reports": ["read", "export"]
        }
    }
}
```

### **Cenário 2: Employee sem User (Funcionário interno)**
```json
{
    "employee": {
        "employee_id": 2,
        "employee_name": "Maria Santos",
        "employee_code": "EMP002",
        "position_id": 4,
        "salary": 15000,
        "username": "maria.santos",
        "user_id": null  // Sem acesso ao sistema
    }
}
```

## 📊 **Fluxo de Autenticação**

### **1. Login via Users (Sistema Principal)**
```javascript
// Usuário faz login
POST /api/auth/signin
{
    "username": "joao.silva",
    "password": "senha123"
}

// Sistema verifica na tabela users
// Retorna token com role e permissions
```

### **2. Login via Employees (Sistema Interno)**
```javascript
// Funcionário faz login interno
POST /api/employees/login
{
    "username": "maria.santos",
    "password": "senha123"
}

// Sistema verifica na tabela employees
// Retorna dados do funcionário
```

## 🎯 **Casos de Uso**

### **Gerente (Tem User + Employee)**
- ✅ **Login**: Via tabela `users` com role "manager"
- ✅ **Permissões**: Acesso total ao sistema
- ✅ **Dados RH**: Salário, posição, etc. na tabela `employees`

### **Agente de Campo (Só Employee)**
- ✅ **Login**: Via tabela `employees` (sistema interno)
- ✅ **Permissões**: Limitadas ao sistema interno
- ✅ **Dados RH**: Completos na tabela `employees`

### **Cliente (Só User)**
- ✅ **Login**: Via tabela `users` com role "customer"
- ✅ **Permissões**: Apenas seus próprios dados
- ❌ **Dados RH**: Não aplicável

## 🔧 **Implementação Prática**

### **Criar Employee com User:**
```javascript
// 1. Criar user primeiro
const user = await UserModel.create({
    username: "joao.silva",
    password: "senha123",
    role: "manager",
    permissions: { /* ... */ }
});

// 2. Criar employee com relacionamento
const employee = await EmployeeModel.create({
    employee_name: "João Silva",
    employee_code: "EMP001",
    position_id: 1,
    salary: 25000,
    username: "joao.silva",
    password: "senha123",
    user_id: user.user_id  // Relacionamento
});
```

### **Criar Employee sem User:**
```javascript
// Criar apenas employee
const employee = await EmployeeModel.create({
    employee_name: "Maria Santos",
    employee_code: "EMP002",
    position_id: 4,
    salary: 15000,
    username: "maria.santos",
    password: "senha123"
    // user_id: null (padrão)
});
```

## ✅ **Benefícios da Nova Arquitetura**

1. **🎯 Separação Clara**: Users para auth, Employees para RH
2. **🔄 Flexibilidade**: Employee pode ter ou não acesso ao sistema
3. **📊 Consistência**: Um único sistema de roles e permissions
4. **🔒 Segurança**: Controle de acesso centralizado
5. **📈 Escalabilidade**: Fácil adicionar novos tipos de usuários
6. **🛠️ Manutenção**: Menos redundância, mais clareza

## 🚀 **Próximos Passos**

1. ✅ **Remover campo `role` de employees** - CONCLUÍDO
2. ✅ **Adicionar campo `user_id` em employees** - CONCLUÍDO
3. ✅ **Atualizar controller de employees** - CONCLUÍDO
4. 🔄 **Implementar relacionamento automático** - PENDENTE
5. 🔄 **Criar endpoints de login para employees** - PENDENTE
6. 🔄 **Atualizar documentação da API** - PENDENTE

## 📝 **Resumo**

**Agora temos uma arquitetura limpa e bem definida:**
- **Users**: Autenticação, autorização, permissões
- **Employees**: Dados de RH, folha de pagamento, estrutura organizacional
- **Relacionamento**: Opcional, via `user_id`

**Não há mais confusão sobre roles - tudo centralizado na tabela `users`!** 🎉