David
dac22372b9
- Archived historical documents for DTO design and naming conventions. - Added normative documentation for HTTP request flow and module boundaries. - Introduced testing guidelines for backend layers. - Updated onboarding module documentation and clarified onboarding requirements. - Deprecated backend prompt base and prompt auth documents. - Adjusted paths in testing documentation for consistency.
2.3 KiB
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
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.