Refinamento Arquitetural - Sprint 1

Visão Geral da Arquitetura

A Sprint 1 estabelece a base arquitetural para todo o sistema de feedback, focando no microserviço de gerenciamento de usuários e na infraestrutura de autenticação. Esta arquitetura segue os princípios de Domain-Driven Design (DDD) e microserviços, permitindo escalabilidade e manutenibilidade.

Componentes Arquiteturais

Microserviço de Gerenciamento de Usuários

O microserviço de gerenciamento de usuários é responsável por:

Autenticação: Validar credenciais e gerar tokens JWT
Gestão de Usuários: CRUD de colaboradores, PDMs e administradores
Autorização: Definir e verificar permissões baseadas em papéis

Biblioteca de Segurança

Uma biblioteca compartilhada de segurança será desenvolvida para encapsular a lógica de autenticação e autorização, permitindo sua reutilização em outros microserviços.

Frontend

O frontend será desenvolvido com Next.js, utilizando uma arquitetura de componentes React e integração com o backend via API RESTful.

Decisões Arquiteturais

1. Autenticação Stateless com JWT

Decisão: Utilizar JWT (JSON Web Tokens) para autenticação stateless.

Justificativa:

Permite escalabilidade horizontal sem necessidade de sessões compartilhadas
Facilita a integração entre microserviços
Reduz a carga no banco de dados ao eliminar consultas frequentes para validação de sessão

Implicações:

Necessidade de gerenciar a expiração e renovação de tokens
Impossibilidade de invalidar tokens individuais sem implementação adicional
Tamanho do payload do token impacta o tamanho das requisições

2. Biblioteca de Segurança Compartilhada

Decisão: Criar uma biblioteca compartilhada para lógica de segurança.

Justificativa:

Evita duplicação de código entre microserviços
Garante consistência na implementação de segurança
Facilita atualizações e correções de segurança

Implicações:

Necessidade de gerenciar versões da biblioteca
Acoplamento entre microserviços e biblioteca
Necessidade de testes rigorosos para evitar regressões

3. Soft Delete para Usuários

Decisão: Implementar soft delete para desativação de usuários.

Justificativa:

Preserva histórico de ações e relacionamentos
Permite reativação de usuários se necessário
Mantém integridade referencial no banco de dados

Implicações:

Necessidade de filtrar usuários inativos em consultas
Aumento do tamanho do banco de dados ao longo do tempo
Complexidade adicional em queries e índices

4. Separação de Banco de Dados por Microserviço

Decisão: Cada microserviço terá seu próprio banco de dados.

Justificativa:

Isolamento de dados e autonomia dos microserviços
Possibilidade de escolher o banco de dados mais adequado para cada contexto
Redução de pontos únicos de falha

Implicações:

Necessidade de gerenciar consistência eventual entre serviços
Complexidade adicional em consultas que envolvem dados de múltiplos serviços
Overhead de manutenção de múltiplos bancos de dados

Padrões Arquiteturais Aplicados

1. Domain-Driven Design (DDD)

O microserviço de gerenciamento de usuários seguirá os princípios do DDD:

Entidades: Usuario como entidade principal com identidade própria
Objetos de Valor: UsuarioLogado como representação imutável do usuário autenticado
Agregados: Usuario como raiz de agregado, encapsulando regras de negócio
Repositórios: Interfaces para persistência de agregados
Serviços de Domínio: Lógica de negócio que não pertence naturalmente a entidades

2. Arquitetura em Camadas

O microserviço será estruturado em camadas:

Camada de Apresentação: Controllers REST que recebem requisições HTTP
Camada de Aplicação: Serviços que orquestram operações de domínio
Camada de Domínio: Entidades, objetos de valor e regras de negócio
Camada de Infraestrutura: Implementações de repositórios e serviços externos

3. API Gateway

Um API Gateway será implementado para:

Roteamento de requisições para os microserviços apropriados
Autenticação centralizada
Logging e monitoramento
Transformação de requisições e respostas

4. CQRS Simplificado

Separação conceitual entre operações de leitura e escrita:

Comandos: Operações que modificam o estado (criar, atualizar, desativar usuários)
Consultas: Operações que apenas leem o estado (listar usuários, buscar por ID)

Considerações de Segurança

1. Armazenamento Seguro de Senhas

Utilização de BCrypt para hash de senhas
Configuração apropriada de fatores de custo para o algoritmo
Nenhum armazenamento de senhas em texto plano

2. Proteção contra Ataques Comuns

Validação de entrada para prevenir injeção SQL e XSS
Configuração adequada de CORS para prevenir requisições cross-origin não autorizadas

3. Segurança em Profundidade

Validação de tokens JWT em cada requisição
Verificação de permissões baseada em roles
Logs de auditoria para ações sensíveis
Multi Factor Authentication (MFA) para garantir que usuário se logando é realmente dono do recurso