菜单
Designs NestJS feature modules with clean dependency boundaries, provider scopes, and dynamic modules. Use when adding a new feature module, splitting a monolithic AppModule, or fixing tangled imports between modules.
| name | architecting-nestjs-modules |
| description | Designs NestJS feature modules with clean dependency boundaries, provider scopes, and dynamic modules. Use when adding a new feature module, splitting a monolithic AppModule, or fixing tangled imports between modules. |
| license | MIT |
AppModuleScope.DEFAULT (singleton), use Scope.REQUEST only when needed@Module({
controllers: [UserController],
providers: [
CreateUserUseCase,
{ provide: 'UserRepository', useClass: TypeOrmUserRepository },
],
exports: [CreateUserUseCase],
})
export class UserModule {}
@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],
};
}
}
// Clean module boundary
@Module({ controllers: [OrderController], providers: [OrderService], exports: [OrderService] })
export class OrderModule {}
// ❌ Monolithic AppModule
@Module({ controllers: [UserController, OrderController, ProductController], providers: [...] })
export class AppModule {}
See reference/module-patterns.md for full patterns.
Defines the rule base every skill in this pack obeys: file layout, frontmatter, vocabulary, OOP/typing/decoupling axioms, and anti-patterns. Load FIRST before authoring or applying any other skill in this pack.
Builds thin NestJS controllers that parse input, invoke a single use case, and map the Result to ApiResponse<T>. Use when adding HTTP endpoints, refactoring fat controllers, or applying API versioning.
Prepares a NestJS service for production: graceful shutdown, health/readiness, structured logs, config, Dockerfile, CI gates, and rollout safety. Use when promoting a service to staging/production or auditing readiness.
Designs NestJS application services as use-case classes that orchestrate domain logic and ports without leaking the framework. Use when creating new use cases, refactoring services that mix HTTP/DB/domain, or moving from anemic services to OOP.
Maps internal AppError hierarchy to HTTP responses through a single global exception filter and a Result-to-HttpException helper. Use when adding new error types, fixing inconsistent error responses, or removing scattered try/catch in controllers.
Implements the Repository pattern with TypeORM in NestJS so domain entities stay framework-free, ORM models live in infrastructure, and transactions are explicit. Use when adding persistence, refactoring leaky ORM usage, or handling transactions across aggregates.