Refinamiento Arquitectónico - Sprint 1

Visión General de la Arquitectura

El Sprint 1 establece la base arquitectónica para todo el sistema de feedback, centrándose en el microservicio de gestión de usuarios y en la infraestructura de autenticación. Esta arquitectura sigue los principios de Domain-Driven Design (DDD) y microservicios, permitiendo escalabilidad y mantenibilidad.

Componentes Arquitectónicos

Microservicio de Gestión de Usuarios

El microservicio de gestión de usuarios es responsable de:

Autenticación: Validar credenciales y generar tokens JWT
Gestión de Usuarios: CRUD de colaboradores, PDMs y administradores
Autorización: Definir y verificar permisos basados en roles

Librería de Seguridad

Se desarrollará una librería compartida de seguridad para encapsular la lógica de autenticación y autorización, permitiendo su reutilización en otros microservicios.

Frontend

El frontend se desarrollará con Next.js, utilizando una arquitectura de componentes React e integración con el backend a través de una API RESTful.

Decisiones Arquitectónicas

1. Autenticación sin estado (Stateless) con JWT

Decisión: Utilizar JWT (JSON Web Tokens) para la autenticación sin estado.

Justificación:

Permite la escalabilidad horizontal sin necesidad de sesiones compartidas
Facilita la integración entre microservicios
Reduce la carga en la base de datos al eliminar consultas frecuentes para la validación de sesión

Implicaciones:

Necesidad de gestionar la expiración y renovación de tokens
Imposibilidad de invalidar tokens individuales sin una implementación adicional
El tamaño del payload del token impacta el tamaño de las solicitudes

2. Librería de Seguridad Compartida

Decisión: Crear una librería compartida para la lógica de seguridad.

Justificación:

Evita la duplicación de código entre microservicios
Garantiza la consistencia en la implementación de seguridad
Facilita las actualizaciones y correcciones de seguridad

Implicaciones:

Necesidad de gestionar las versiones de la librería
Acoplamiento entre los microservicios y la librería
Necesidad de pruebas rigurosas para evitar regresiones

3. Eliminado Lógico (Soft Delete) para Usuarios

Decisión: Implementar el eliminado lógico para la desactivación de usuarios.

Justificación:

Conserva el historial de acciones y relaciones
Permite la reactivación de usuarios si es necesario
Mantiene la integridad referencial en la base de datos

Implicaciones:

Necesidad de filtrar usuarios inactivos en las consultas
Aumento del tamaño de la base de datos con el tiempo
Complejidad adicional en las consultas e índices

4. Separación de Base de Datos por Microservicio

Decisión: Cada microservicio tendrá su propia base de datos.

Justificación:

Aislamiento de datos y autonomía de los microservicios
Posibilidad de elegir la base de datos más adecuada para cada contexto
Reducción de puntos únicos de fallo

Implicaciones:

Necesidad de gestionar la consistencia eventual entre servicios
Complejidad adicional en consultas que involucran datos de múltiples servicios
Sobrecosto de mantenimiento de múltiples bases de datos

Patrones Arquitectónicos Aplicados

1. Domain-Driven Design (DDD)

El microservicio de gestión de usuarios seguirá los principios de DDD:

Entidades: Usuario como entidad principal con identidad propia
Objetos de Valor: UsuarioLogado como representación inmutable del usuario autenticado
Agregados: Usuario como raíz de agregado, encapsulando reglas de negocio
Repositorios: Interfaces para la persistencia de agregados
Servicios de Dominio: Lógica de negocio que no pertenece naturalmente a las entidades

2. Arquitectura en Capas

El microservicio se estructurará en capas:

```mermaid block-beta columns 2 block:presentation A["Controladores"]:1 end Presentación["Capa de Presentación"]:1

block:application
    B["Servicios"]:1
end
Aplicación["Capa de Aplicación"]:1

block:domain
    C["Objetos de Dominio"]:1
end
Dominio["Capa de Dominio"]:1

block:infra
    D["Repositorios"]:1
end
Infraestructura["Capa de Infraestructura"]:1

Presentación ----> presentation
Aplicación