Skip to main content

Patrones de diseño del backend

El código de ABA-backend está organizado en capas que existen exclusivamente para que la regla de Database-Centric sea fácil de respetar y difícil de romper por accidente.

Estructura de carpetas​

ABA-backend/
Controllers/    Auth, Provisioning, Dashboard, Landing, células socias, DNS, N8N, sesiones...
Services/       CookieJwtService, RateLimitPolicies, PasswordGenerator, ProvisioningOrchestrator,
                ProvisioningRetryService, MySqlQuotaEnforcementService, MySqlProvisioningService
Repositories/   Interfaces/ (contratos) + SqlServer/ (implementaciones que solo invocan SPs)
Contracts/      DTOs con validación estricta — propiedades no mapeadas se rechazan globalmente
Middleware/     ExceptionHandling, SecurityHeaders, RequestAudit — aplicados a todo, no por controller
sql/            Scripts numerados, se ejecutan en orden estricto
infra/          Hardening de sistema operativo/kernel para el VPS

Repository Pattern + Inversión de Dependencias (DIP)​

Cada controller depende únicamente de una interfaz en Repositories/Interfaces/. La implementación real vive en Repositories/SqlServer/ y no hace nada más que:

  1. Abrir una llamada parametrizada a un Stored Procedure.
  2. Leer el resultado.
  3. Mapear cada fila a un DTO tipado de Contracts/.

Ningún controller ni service instancia una conexión SQL directamente — siempre pasa por la interfaz. Esto es lo que permite que el código de aplicación nunca "sepa" reglas de negocio: solo conoce la forma de entrada y salida del SP, nunca su contenido.

DTOs con validación estricta​

Los contratos de entrada (Contracts/) rechazan cualquier propiedad JSON no mapeada explícitamente — un intento de mandar campos extra en el body de un request falla antes de llegar al controller. Esto cierra la puerta a ataques de asignación masiva (mass assignment) sin que haga falta lógica adicional en cada endpoint.

Middleware transversal, no por controller​

Middleware/ se aplica globalmente en el pipeline, no como filtro por endpoint:

  • ExceptionHandlingMiddleware envuelve toda la ejecución — ninguna excepción sin manejar filtra detalles internos (stack traces, mensajes de SQL Server) al cliente.
  • SecurityHeadersMiddleware agrega cabeceras de seguridad a cada respuesta.
  • RequestAuditMiddleware registra el código de estado final y el usuario resuelto de cada request, después de que pasó por autenticación y autorización.

Orchestrator: coordinar dos motores sin filtrar lógica​

ProvisioningOrchestrator es la única pieza de Services/ que toca ambos motores (SQL Server y MySQL) en la misma operación — pero no decide nada, solo coordina el orden: primero reserva el registro en MasterControl vía SP, después ejecuta el aprovisionamiento real en MySQL, y si ese segundo paso falla, revierte el primero en la misma operación. La decisión de qué nombre usar, qué cuota aplica o si el usuario puede aprovisionar ya viene resuelta por el SP antes de este paso — el orchestrator solo ejecuta la secuencia.

Este patrón (SP primero, motor externo después, rollback en la misma operación si falla) es el que mantiene la garantía descrita en Visión General: ninguna base queda "activa" en el plano de control sin existir realmente en MySQL.