Injeção de dependências

O NestJS concentra o wiring em módulos globais em vez de módulos por feature.

DatabaseModule — padrão central

Arquivo: src/infra/database/database.module.ts

Registra ~52 bindings no formato:

{
  provide: QueueRepositoryGateway,
  useClass: KnexQueueRepository,
}

Também registra providers de conexão:

• CompanyKnexProvider — banco por empresa
• AdminKnexProvider — catálogo admin
• AdminDynamicKnexProvider — conexões dinâmicas admin

Exports: todas as classes abstratas de gateway, para que módulos importadores possam injetá-las.

Módulos transversais

HTTPModule

@Module({
  imports: [EncryptModule, DatabaseModule, S3Module, BrokerModule, RedisModule, EmailModule, ReportsModule],
  controllers: [...CONTROLLERS],
  providers: [
    ...SERVICES,      // src/external/* — microserviços
    ...USECASES,      // src/app/use-cases/*
    { provide: APP_GUARD, useClass: GCIPermissionGuard },
    { provide: APP_GUARD, useClass: CustomerGuard },
  ],
})

Diagrama de injeção

Regras de DI

1. Gateways: sempre provide: AbstractClass, useClass: ConcreteClass.
2. Use cases: registrados diretamente no array providers (sem useClass).
3. Controllers: injetam use cases pelo tipo da classe.
4. Use cases injetam gateways pelo tipo abstrato no constructor — o Nest resolve automaticamente se o gateway estiver em exports de um módulo importado.

Próximos tópicos

• Padrão Gateway
• Exceções pragmáticas — S3 e microserviços sem gateway