Este documento es la referencia oficial (“Biblia”) de la arquitectura técnica, decisiones de diseño estructurales y convenciones del sistema backend del proyecto.
El propósito global del backend es proveer una API RESTful robusta, predecible y altamente mantenible para la gestión académica e institucional (sistema de módulos para estudiantes, registros de asistencia, usuarios, etc.). Está diseñado para soportar procesos críticos empresariales a través de reglas de auto-sanación, consistencia estricta en base de datos y un empaquetado seguro.
bun:test como motor unificado para la suite de testing (unitario y de integración) por su extrema velocidad y soporte nativo para TypeScript.El proyecto no acopla la lógica de negocio al Framework ni a la Base de Datos. Implementamos estricta y rígidamente el modelo de Clean Architecture (Arquitectura Limpia). Las dependencias siempre apuntan hacia adentro, aislando el dominio de los detalles de implementación mediante Inversión de Dependencias (Interfaces).
Cada sub-módulo dentro del sistema respeta 4 capas fundamentales:
domain/)Es el corazón del software. No tiene dependencias externas (ni de Express, ni Sequelize).
StudentLevelEntity).Repositories, DataSources). Dictan qué debe poder hacerse, pero no cómo.ClassName.create(object)) que sirve como barrera infranqueable de validación, asegurando que la data ingresada a la lógica pura posea formatos correctos o retornando un error temprano.application/)Orquesta el flujo del software.
PurchaseModules). Un Caso de Uso inyecta un Repositorio (una interfaz) y ejecuta una acción, delegando lógicas técnicas y devolviendo Entidades puras hacia las capas externas.presentation/)