Original skill document
Rendered from the source repository. Headings, examples, code, tables, links, and referenced images are preserved.
Architecting NestJS Modules
When to use
- Adding a new feature module
- Splitting a monolithic
AppModule - Fixing tangled imports between modules
Core rules
- Feature modules own their domain, application, infrastructure layers
- Providers default to
Scope.DEFAULT(singleton), useScope.REQUESTonly when needed - Export only what other modules need (don't export everything)
- Dynamic modules for configurable features (database, cache)
- No cross-feature imports; use shared contracts
Reference shape (TypeScript)
Feature Module
typescript
@Module({
controllers: [UserController],
providers: [
CreateUserUseCase,
{ provide: 'UserRepository', useClass: TypeOrmUserRepository },
],
exports: [CreateUserUseCase],
})
export class UserModule {}Dynamic Module Example
typescript
@Module({})
export class DatabaseModule {
static register(config: DatabaseConfig): DynamicModule {
return {
module: DatabaseModule,
providers: [
{ provide: 'DATABASE_CONFIG', useValue: config },
{ provide: DataSource, useFactory: () => new DataSource(config).initialize() },
],
exports: [DataSource],
};
}
}Examples — Do
typescript
// Clean module boundary
@Module({ controllers: [OrderController], providers: [OrderService], exports: [OrderService] })
export class OrderModule {}Examples — Don't
typescript
// ❌ Monolithic AppModule
@Module({ controllers: [UserController, OrderController, ProductController], providers: [...] })
export class AppModule {}Checklist
- [ ] Feature modules with own layers
- [ ] Providers with appropriate scopes
- [ ] Only necessary exports
- [ ] No cross-feature imports
See reference/module-patterns.md for full patterns.
