40 lines
2.3 KiB
Markdown
40 lines
2.3 KiB
Markdown
|
# Inyección de dependencias por módulo
|
||
|
|
|
||
|
|
> Estado: **NORMATIVO**. Esta guía define cómo se ensambla un módulo backend.
|
||
|
|
|
||
|
|
## Regla base
|
||
|
|
|
||
|
|
Cada módulo tiene un único composition root identificable. Usa constructor injection explícita; no usa contenedor DI, Service Locator, decorators, reflection ni registry dinámico interno.
|
||
|
|
|
||
|
|
El composition root es el único lugar que puede resolver servicios públicos de otros módulos mediante `getService`. Las DI inferiores reciben todas sus dependencias como argumentos explícitos y nunca llaman a `getService`.
|
||
|
|
|
||
|
|
## Responsabilidades del composition root
|
||
|
|
|
||
|
|
El root ensambla infraestructura concreta, repositories, transaction managers, servicios de Application, InputMappers y UseCases. También decide qué instancias se crean una vez y se comparten, y devuelve las APIs `services` e `internal` del módulo.
|
||
|
|
|
||
|
|
Las DI inferiores pueden separarse por responsabilidad: persistence, application services, mappers, use cases o recurso. No hay obligación de reducir ficheros: la claridad del grafo de dependencias es prioritaria a tener menos ficheros. La duplicación explícita entre composition roots es preferible a una abstracción DI prematura.
|
||
|
|
|
||
|
|
No introducir `GenericDI`, `BaseDI`, registry DI, contenedor global ni imports de repositories de otro módulo.
|
||
|
|
|
||
|
|
## `services` e `internal`
|
||
|
|
|
||
|
|
```text
|
||
|
|
services = API pública intermodular
|
||
|
|
internal = API privada del propio módulo
|
||
|
|
```
|
||
|
|
|
||
|
|
`services` contiene únicamente contratos con consumidores intermodulares reales. Por YAGNI no se expone nada “por si acaso”. Nunca expone repositories, mappers de persistencia, transaction managers ni use cases HTTP sin consumidor externo.
|
||
|
|
|
||
|
|
`internal` puede contener use cases, application services u otras dependencias privadas que necesiten el arranque o las routes. No debe convertirse en una copia indiscriminada del composition root.
|
||
|
|
|
||
|
|
Un módulo externo consume `services`; nunca consume `internal` de otro módulo.
|
||
|
|
|
||
|
|
## Ejemplo mínimo
|
||
|
|
|
||
|
|
El root de onboarding crea persistence, resuelve `companies:general` e `identity:general`, construye use cases y devuelve sus dependencias privadas. Véase `modules/onboarding/src/api/infrastructure/di/onboarding.di.ts`.
|
||
|
|
|
||
|
|
## Referencias
|
||
|
|
|
||
|
|
- [Límites entre módulos](./module-boundaries.md)
|
||
|
|
- [Flujo HTTP](./http-request-flow.md)
|