Aurora Engine — Plataforma ERP Multiempresa
Plataforma de aplicación vertical con el Libro Mayor como kernel: un ERP SaaS multiempresa (schema-per-tenant) con un generador declarativo de módulos que emite paquetes ya cableados y validados por arquitectura, convirtiendo cada módulo nuevo de semanas de plomería frágil en horas.
Resultados Clave
Tiempo de un módulo nuevo
Calidad de arquitectura, no suerte
Problema y Solución
El Problema
El software de gestión a medida no escala: cada cliente se vuelve un fork, cada módulo reinventa el cableado y la calidad depende del programador del día. Construir software de grado financiero — integridad de partida doble, aislamiento multiempresa, reglas fiscales por país — a mano es lento y propenso a errores.
La Solución
Diseñé Aurora Engine como un kernel (el GL tratado como un protocolo de event-log) con un SDK de plataforma de contratos y un generador determinístico (aurora:make-module) que estampa módulos canónicos ya cableados. Las invariantes arquitectónicas se aplican como fitness functions en CI: el dinero siempre es BCMath, el aislamiento por empresa no puede filtrarse y los satélites nunca tocan el libro mayor directo.
Stack Tecnológico
Caso de Estudio
El GL como Kernel, la Arquitectura como Producto
El Desafío: La Artesanía no Escala
Cada Cliente, un Fork
El software de gestión a medida tiende a ramificarse por cliente. Cada nueva empresa o vertical reinventa el mismo cableado (autenticación, multiempresa, permisos, reportes), multiplicando el costo de mantenimiento y la superficie de error.
Calidad Dependiente de la Persona
Sin barreras embebidas, la integridad financiera (partida doble, dinero exacto sin floats, aislamiento entre empresas) depende de que el desarrollador del día recuerde la regla. La disciplina humana no es una garantía de arquitectura.
Rigidez Fiscal y Regional
Quemar reglas de un país (IVA, ISR, FEL/SAT de Guatemala) en el código bloquea la expansión a otras geografías y obliga a reescrituras costosas con cada cambio normativo.
La Solución Arquitectónica: Kernel + SDK + Generador
El Libro Mayor como Protocolo
El kernel es el GL, tratado como un event-log de dos hechos irreducibles (asientos y conciliaciones). Toda operación con efecto financiero queda asentada; los reportes son proyecciones regenerables. Los módulos satélite orbitan ese núcleo: algunos asientan movimientos y generan consecuencias financieras directas, otros solo emiten eventos y no postean — pero ninguno toca las líneas del asiento por dentro; todos pasan por el mismo protocolo.
Aurora Platform SDK + Generador
Un SDK de contratos runtime y un generador determinístico (aurora:make-module) convierten un manifiesto declarativo en un paquete ya cableado: provider, plugin, permisos, migraciones y tests, todo emitido por construcción. El generador emite la misma estructura canónica sin variación humana.
Calidad Embebida en la Línea (Fitness Functions)
Las invariantes arquitectónicas se verifican como tests de arquitectura en CI: el dinero es BCMath, el aislamiento multiempresa no puede filtrarse, los inserts masivos llevan su empresa, las cuentas se resuelven por determinación y no por código. Un módulo que viola una norma no compila.
El Impacto: Costo Marginal Decreciente
De Semanas a Horas
Un módulo que antes era semanas de cableado frágil hoy nace verde y auditado a partir de un manifiesto. A medida que el catálogo crece, el costo marginal de la siguiente implementación decrece.
Extensibilidad por País
Las reglas fiscales viven en estrategias y catálogos por país (no en el código de cálculo), habilitando la expansión LATAM sin reescribir el motor. Un nuevo formato fiscal es un proveedor nuevo, no un fork.
Engine Reutilizable, no Boilerplate
Aurora Engine es la base sobre la que nacen productos SaaS reales sin forkear el kernel. Es una plataforma de aplicación vertical —arquitectura como producto—, no un app-builder horizontal.