Aurora Platform SDK
El Aurora Platform SDK es el conjunto de contratos runtime estables sobre los que se construye cada módulo. Un satélite habla con el kernel a través de interfaces congeladas —postear al libro mayor, resolver impuestos, consultar inventario, aportar onboarding— y nunca importa el módulo del libro mayor. La implementación del kernel evoluciona por debajo sin romper a nadie.
El planteamiento
En Aurora el kernel es el GL: el libro mayor donde toda operación se asienta. La regla de gravedad establece que todo módulo orbita ese kernel y ninguno escribe en journal_lines de forma directa. El problema clásico de esa arquitectura es el acoplamiento: si cada módulo dependiera de las clases concretas del módulo del libro mayor, cambiar una firma del kernel rompería N módulos en silencio y la plataforma dejaría de poder evolucionar.
El Aurora Platform SDK resuelve eso con una frontera explícita. Vive en los paquetes packages/aurora/platform-contracts y platform-support, y publica un puñado de interfaces y eventos que describen lo que un módulo puede pedirle a la plataforma, no cómo la plataforma lo cumple. Un módulo de Ventas no sabe que existe un módulo llamado Quorum; sabe que existe un contrato CreatesJournalEntries y lo usa. Esa indirección es lo que permite que Ventas, Inventario, CRM, Diferidos y el resto convivan, posteen al mismo libro mayor y sigan compilando cuando el kernel cambia por dentro.
Un módulo asienta al libro mayor por las costuras del SDK: arma los datos del asiento contra una interfaz y el adaptador del host ejecuta el posteo canónico. El satélite nunca importa el módulo del libro mayor ni escribe journal_lines.
CreatesJournalEntries
Impuestos y retenciones se resuelven a través de una interfaz, no de reglas quemadas en cada módulo. El módulo declara el contexto fiscal y recibe los efectos calculados, lo que mantiene la lógica tributaria del país en un solo lugar.
ResolvesTaxEffects
Un módulo de front-office consulta disponibilidad de stock y resuelve la bodega por defecto vía contratos, sin acoplarse a la implementación de valuación perpetua. El consumo de stock viaja como evento del SDK.
ChecksStockAvailability
Cada módulo contribuye sus checks de readiness por empresa implementando un contrato y registrándose en el OnboardingRegistry. El kernel no conoce a los satélites; ellos aportan qué falta configurar.
ProvidesOnboarding
El módulo arma el asiento contra esta interfaz del SDK. El host la implementa y ejecuta el posteo canónico al GL; el satélite jamás importa el módulo del libro mayor.
<?php
declare(strict_types=1);
namespace Aurora\Platform\Contracts\Posting;
/**
* Costura de posteo del SDK. Un módulo satélite arma los datos
* del asiento y los entrega aquí; el adaptador del host hace el
* forceFill canónico (source, source_module, source_id) y postea
* al GL. El satélite nunca importa el módulo del libro mayor ni escribe
* en journal_lines de forma directa.
*/
interface CreatesJournalEntries
{
public function create(JournalEntryData $data): JournalEntryResult;
}
interface PostsJournalEntries
{
public function post(JournalEntryResult $entry): void;
}
// PlatformContractsFreezeTest congela esta superficie: un cambio
// de firma falla ruidoso en CI, en vez de romper N módulos en silencio.Aurora Make
El generador que emite cada módulo ya cableado a estos contratos desde un manifiesto module.yaml.
Aurora Runtime
La infraestructura compartida —ModuleRegistry, OnboardingRegistry, multiempresa— que cumple lo que el SDK promete.
Aurora Architecture
Los ADRs y fitness functions que congelan la superficie del SDK y vigilan la frontera en cada build.
Cómo funciona
El loop completo: del manifiesto al módulo que postea al GL por las costuras del SDK.
Casos de uso
Qué se construye sobre Aurora: ERP y gestión financiera, CRM, nómina, inventario y analítica.
Los contratos cobran sentido cuando se ve cómo un manifiesto se convierte en un módulo cableado que postea al libro mayor sin tocar el kernel. Recorre el ciclo completo o escríbenos para discutir tu caso.