metis-desk/docs/arquitectura/composicion-de-modulos.md

28 lines
1.5 KiB
Markdown
Raw Normal View History

# 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](../estructura-web-por-entidades-y-operaciones.md).
`./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.