NestJS dependency injection

NestJS строит dependency graph при bootstrap: параметры constructor с type metadata резолвятся в зарегистрированные providers. Modules контролируют видимость — provider injectable только где module imported и provider exported.

					const MAILER = Symbol('MAILER');

@Module({
  providers: [
    { provide: MAILER, useClass: SmtpMailer },
    { provide: UsersService, useClass: UsersService },
  ],
  exports: [UsersService, MAILER],
})
export class UsersModule {}
				

`@Inject(TOKEN)` связывает interfaces и custom tokens. `forwardRef` разрывает circular constructor dependencies. В тестах — `TestingModule.overrideProvider`.

На интервью: Nest DI против manual singletons, правила module visibility, как request-scoped injection распространяется на зависимые providers.

Типовые ошибки: inject concrete classes вместо tokenized interfaces, circular module graphs, глобальная доступность без `exports`.

Компромисс — между простотой, производительностью, безопасностью и эксплуатацией: назовите, что оптимизировали и какую цену приняли.

Чеклист:

• Constructor injection, не property.
• Токены для ports/adapters и test seams.
• Явный export providers между modules.
• Override в тестах, не production hacks.