# 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.

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.