Basado en el análisis de negocio y buenas prácticas, la arquitectura está basada en Arquitectura por Servicios ya que la intención es crear un sistema estable, escalable y que nos permita crear servicios que encapsulen lógica volátil permitiendo un bajo o nulo acoplamientos entre los servicios a crear.
Para este sistema, la relación más crítica es la de Usuarios y Tareas. El requerimiento especifica que una tarea puede tener más de un usuario asignado, lo que nos obliga a implementar una relación de muchos a muchos (M:N) mediante una tabla asociativa.
Tabla: users
| Columna | Descripción |
|---|---|
| id | Identificador único del usuario |
| name | Nombre completo del usuario |
| Correo electrónico para login y filtros | |
| role | Rol para control de acceso y filtros |
| created_at | Fecha de creación |
| updated_at | Fecha de última actualización |
Tabla: tasks
| Columna | Descripción |
|---|---|
| id | Identificador único de la tarea |
| title | Título descriptivo de la tarea |
| description | Detalle extenso de los requerimientos |
| estimated_hours | Horas estimadas de esfuerzo |
| due_date | Fecha límite de entrega |
| status | Estado actual de la tarea |
| cost | Costo monetario |
| created_at | Fecha de creación |
| updated_at | Fecha de última actualización |
Tabla: task_assignments
| Columna | Descripcion |
|---|---|
| task_id | Relacion con la tarea |
| user_id | Relación con el usuario |
Este ERD representa la estructura actual de la base de datos del proyecto. Es un modelo relacional clásico con normalización alcanzando específicamente la Tercera Forma Normal (3NF).
Para evitar un acoplamiento en el sistema, se dividirá según su volatilidad (qué tanto cambia) para proceder a descomponerlo en servicios antes de desarrollar una arquitectura para el backend y frontend.