1.5 KiB
Composición de módulos
Cada módulo funcional tendrá un composition root explícito: construye sus dependencias y devuelve únicamente las APIs necesarias para sus consumidores.
Usar constructor injection. No usar Service Locator, contenedores DI, decoradores ni resolución implícita. No copiar el registro dinámico del ERP: esta aplicación todavía no necesita esa capacidad.
Las rutas reciben dependencias ya construidas. No construyen repositorios, servicios de Application ni mappers de dominio.
Cuando sea necesario distinguir superficies:
- services: servicios públicos consumidos por otros módulos.
- internal: dependencias privadas necesarias para las rutas del propio módulo.
No exportar repositorios ni modelos ORM a otros módulos. No crear contratos públicos sin consumidores.
Superficie web de los módulos
Al crear un módulo con código de navegador o ampliar uno existente, aplicar la
estructura web por entidades y operaciones.
./client apunta a src/web/index.ts cuando exista una API web pública con consumidores.
Ese índice compone contratos internos explícitos; no expone automáticamente todas las
entidades, operaciones o componentes del módulo. ./common y ./module mantienen sus
fronteras de contratos compartidos y composición del servidor.
En esta entrega core expone registerCoreRoutes mediante ./module, una frontera de composición del servidor. ./common expone contratos y ./client expone la página y recursos de traducción. No hay dependencias locales del ERP.