Descubrimiento por registro
Cada paquete se auto-registra en el boot() de su proveedor mediante composer auto-discovery. El ModuleRegistry conoce los módulos integrados sin acoplamiento manual ni una lista central que mantener a mano.
ModuleRegistry
AURORA RUNTIME
La infraestructura que todos los módulos comparten
Aurora Runtime es la capa donde los módulos se descubren entre sí, declaran su estado de configuración por empresa y operan dentro de un aislamiento multiempresa estricto. Un módulo nuevo hereda todo esto al integrarse, sin escribir infraestructura.
runtime · boot integrado
✓ ModuleRegistry ← Inventory
✓ OnboardingRegistry ← checks
✓ schema-per-tenant aislado
✓ CompanyContext fuera de HTTP
✓ CompanyCreated → siembra
el módulo hereda la infraestructura, no la escribe
El planteamiento
Un módulo de Aurora no arranca solo ni se conecta a mano. Al integrarse al sistema queda dentro de una infraestructura compartida que resuelve los problemas transversales una sola vez: cómo se descubre el módulo, cómo declara su estado de configuración frente a cada empresa, cómo se aísla la información entre clientes y cómo se siembran sus datos por defecto. Esa capa es Aurora Runtime.
El objetivo es que el código de dominio de cada módulo no contenga plomería. El descubrimiento ocurre por auto-registro en el arranque del proveedor del paquete; la verificación de readiness se delega a un registro central; el contexto de empresa es una fuente de verdad única fuera del ciclo HTTP; y el aislamiento entre tenants vive en el esquema de base de datos, no en condicionales dispersos. Quien escribe un módulo se concentra en la lógica del negocio porque la infraestructura ya está ahí.
Readiness por empresa
Cada módulo aporta sus checks de configuración al OnboardingRegistry. El sistema deriva, por empresa, qué falta antes de operar; el contrato ProvidesOnboarding es la superficie estable que el módulo implementa.
OnboardingRegistry
Aislamiento multiempresa
Aislamiento schema-per-tenant sobre Postgres con stancl/tenancy: un esquema por tenant. CompanyContext es la fuente de verdad de la empresa activa fuera de HTTP, en jobs, listeners y comandos.
CompanyContext
Aprovisionamiento por empresa
La sección provisions del manifiesto siembra filas por defecto para cada empresa al crearse, suscrita al evento SDK CompanyCreated. Series por empresa, entitlements por módulo y BelongsToCompany completan el aislamiento.
CompanyCreated
Un proveedor de paquete que se integra al Runtime
Al arrancar, el proveedor del paquete se auto-registra en el ModuleRegistry y aporta sus checks de readiness al OnboardingRegistry. No hay configuración central que tocar: composer auto-discovery carga el proveedor y el resto es declarativo.
InventoryServiceProvider.php
public function boot(): void
{
// Descubrimiento: el paquete se registra a sí mismo en el Runtime.
$this->app->make(ModuleRegistry::class)->register(
new InventoryModuleManifest(),
);
// Readiness por empresa: aporta sus checks al registro central.
$this->app->make(OnboardingRegistry::class)->register(
new InventoryOnboarding(),
);
// Aprovisionamiento por empresa: siembra filas por defecto
// cuando se crea una empresa (evento SDK del Runtime).
Event::listen(
CompanyCreated::class,
ProvisionInventoryOnCompanyCreated::class,
);
}Siga explorando
Aurora Make
El generador por manifiesto que emite un paquete ya cableado al Runtime.
Aurora Platform SDK
Los contratos estables que los módulos implementan, entre ellos ProvidesOnboarding y el evento CompanyCreated.
Aurora Architecture
Las invariantes y fitness functions que protegen el aislamiento y la frontera de cada paquete.
Cómo funciona
El loop completo: del manifiesto al módulo corriendo dentro del Runtime.
Casos de uso
Qué se construye sobre Aurora: ERP y gestión financiera, CRM, nómina, inventario y analítica.
Mira el módulo integrarse al Runtime
El descubrimiento, la readiness por empresa y el aprovisionamiento no se escriben: un módulo los hereda al integrarse. Recorre el loop que va del manifiesto al módulo operando dentro de la infraestructura compartida.