🏛️ Arquitectura General del Sistema — Gestión de Visitas (Túnel Subfluvial)

Este documento describe la arquitectura de software del Sistema de Gestión de Visitas del Túnel Subfluvial, detallando el diseño técnico, la separación de responsabilidades en capas y cómo interactúan las tecnologías principales del stack: React (Frontend), Node.js/Express (Backend) y PostgreSQL (Base de Datos).


1. 🗺️ Diagrama de Arquitectura de Alto Nivel

El sistema sigue una arquitectura cliente-servidor desacoplada. A continuación se presenta el flujo general de comunicación entre los componentes del sistema:

[Diagram]

2. 💻 Capa Cliente (Frontend - React)

El frontend está desarrollado sobre React 18 utilizando TypeScript y compilado con Vite. La interfaz está estilizada usando Tailwind CSS para un diseño moderno y responsivo.

Organización de Código

Comunicación con el Backend

El frontend se comunica con el servidor de forma asíncrona a través de la Fetch API de JavaScript utilizando variables de entorno (import.meta.env.VITE_API_URL) para definir la dirección del servidor.

[!NOTE] Todas las peticiones HTTP que requieren autorización adjuntan el token JWT guardado localmente en las cabeceras de la petición: headers: { 'Authorization': 'Bearer <Token_JWT>' }


3. ⚙️ Capa de Aplicación (Backend - Node.js + Express)

El backend está desarrollado en Node.js con TypeScript, estructurado sobre el framework web Express. Sigue un patrón de arquitectura limpia dividida en 4 capas principales de responsabilidad:

[Cliente] ──> [Middleware (JWT)] ──> [Routes] ──> [Controllers] ──> [Services] ──> [Repositories] ──> [PostgreSQL]

Capas del Backend

  1. Middlewares (src/middleware/):
    • auth.middleware.ts: Intercepta las solicitudes entrantes, extrae el token JWT del encabezado Authorization, lo verifica usando la clave secreta y almacena los datos decodificados en el objeto de la petición (req.usuario). Adicionalmente valida si el rol del usuario posee los permisos adecuados (verificarRol).
  2. Rutas (src/routes/):
    • Define los endpoints del sistema (ej. /api/visitas, /api/usuarios, /api/gestores). Asocia cada ruta con su respectivo controlador y le aplica los middlewares de autenticación necesarios.
  3. Controladores (src/controllers/):
    • Actúan como puntos de entrada de la petición HTTP. Extraen datos de la URL (req.params), de la query string (req.query) o del cuerpo (req.body), delegan la lógica de negocio a los servicios correspondientes y devuelven la respuesta en formato JSON con el código de estado HTTP adecuado.
  4. Servicios (src/services/):
    • Contienen toda la lógica de negocio y reglas operativas del sistema (ej. cálculo de estadísticas, verificación de aforo acumulado, validación de solapamiento de horas, etc.).
    • Es una capa agnóstica del protocolo de transporte (no sabe que existe HTTP).
    • export.service.ts: Utiliza puppeteer-core y @sparticuz/chromium para levantar un navegador headless, renderizar una plantilla HTML en memoria e imprimirla en formato PDF (utilizado para comprobantes individuales de visitas y reportes estadísticos).
  5. Repositorios (src/repositories/):
    • Encapsulan las operaciones directas de lectura y escritura en la base de datos PostgreSQL. Utilizan consultas SQL parametrizadas nativas para máxima performance y seguridad contra inyección de SQL.

4. 🗄️ Capa de Datos (Base de Datos - PostgreSQL)

La persistencia de datos está delegada en PostgreSQL. La conexión se realiza a través de un pool gestionado por el driver de Node pg (Pool), optimizando la reutilización de conexiones TCP.

Diagrama Entidad-Relación (Base de Datos Real)

[Diagram]

Reglas de Negocio Implementadas en Consultas del Backend


5. 🔄 Flujo de una Petición Común: Registro de una Visita

El siguiente diagrama de secuencia detalla cómo viaja la información entre los distintos componentes y capas al registrar una nueva visita guiada (CU-003):

[Diagram]

6. 🔒 Seguridad y Auditoría

La seguridad es transversal a toda la aplicación y se gestiona bajo los siguientes estándares: