AURORA ARCHITECTURE
Aurora Architecture es el conjunto de reglas que gobiernan cómo evoluciona la plataforma: decisiones registradas como ADRs, invariantes transversales y fitness functions que se ejecutan en cada build. Cuando un módulo cruza una frontera prohibida, toca dinero con un float o se desvía de su manifiesto, la suite falla de forma ruidosa antes del merge.
El planteamiento
Una plataforma que dura no se sostiene con disciplina individual ni con revisiones manuales. Se sostiene con reglas ejecutables. En Aurora, las decisiones arquitectónicas se registran como ADRs con un ciclo de vida explícito —Propuesta, Aceptada, Implementada, Obsoleta o Reemplazada— y las invariantes transversales que de ahí derivan se centralizan en el ADR 0017, el checklist obligatorio para todo módulo o decisión nueva.
La diferencia está en que esas invariantes no son recordatorios en un documento: las que pueden expresarse como una propiedad verificable se codifican como fitness functions, tests de arquitectura que corren en cada build. Un paquete que importa el kernel, un módulo cuyo cableado se desvió de su manifiesto, una firma del SDK que cambió en silencio o un cálculo de dinero con punto flotante: cada uno tiene un test que lo detiene. La integridad financiera y la frontera entre módulos dejan de depender de que alguien recuerde la regla en el momento correcto.
Cada cambio estructural se registra como un Architecture Decision Record con estado explícito: Propuesta, Aceptada, Implementada, Obsoleta o Reemplazada. Las invariantes transversales se consolidan en un solo lugar, el checklist obligatorio para todo módulo nuevo.
ADR 0017
Un paquete Aurora nunca importa el código de la aplicación host. La regla se aplica como un test de arquitectura dinámico que recorre cada paquete del repositorio: si su código fuente referencia App\Modules, el build falla.
PackageBoundaryTest
Los contratos runtime del Aurora Platform SDK están protegidos por un test que congela su superficie. Un cambio de firma falla ruidoso en CI en vez de romper N módulos en silencio: los satélites dependen de contratos estables, no de implementaciones.
PlatformContractsFreezeTest
El dinero se opera con BCMath sobre columnas numeric(15,2), nunca con float. Las cuentas del libro mayor se resuelven por su nombre canónico mediante determinación, nunca por código, porque los códigos divergen entre plantillas de cuentas.
numeric(15,2)
Tests de arquitectura (Pest Arch) que se ejecutan en cada build. Cada uno traduce una invariante a una propiedad verificable: si el código se desvía, el build se detiene.
Aurora Make
El generador determinístico que emite paquetes Aurora ya cableados desde un manifiesto module.yaml.
Aurora Platform SDK
Los contratos runtime estables de los que dependen los módulos, en lugar de las implementaciones del kernel.
Aurora Runtime
La infraestructura compartida: ModuleRegistry, OnboardingRegistry, multiempresa y CompanyContext.
Cómo funciona
El loop completo de manifiesto a módulo, de principio a fin.
Casos de uso
Qué se construye sobre Aurora: ERP y gestión financiera, CRM, nómina, inventario y analítica.
Aurora Architecture convierte las decisiones de diseño en tests que corren en cada build. Conoce cómo el manifiesto, los contratos y las invariantes se encadenan en un solo flujo de trabajo.