用途：在 NestJS 项目中设计模块边界与 Provider 归属，帮助划分 Feature Modules（如 Auth）、Core（Config/DB）与 Shared（Utils），并明确 controller 与 service 的职责边界。
主要能力：提供模块角色决策（Feature 拥有自己的 controller、应用服务与适配器；Shared 只导出无状态辅助函数）、Provider 作用域决策（默认 singleton，仅租户上下文、请求级缓存或请求追踪才用 request scope）、请求管线选择（middleware 处理原始 HTTP、guard 做访问决策、pipe 做校验与转换、interceptor 处理横切请求/响应、filter 做错误转换）。
使用方式：按 recipe 创建有界 feature（module + controller + application service + persistence adapter）；保持 controller 薄、service 厚，业务逻辑放 service；依赖只注册一次，imports 用于模块、providers 用于服务、exports 仅给真正消费者，@InjectRepository() 依赖需 TypeOrmModule.forFeature([...])；在边界做 DTO 校验，service 不信任原始 payload；用 madge 检查循环依赖，优先重构契约，forwardRef() 仅作最后手段。
适用场景：需要梳理 NestJS 模块结构、Provider 作用域、请求生命周期组件放置，或排查循环依赖与依赖完整性时。
限制与反模式：不要默认使用 request scope；controller 不放业务逻辑；不直接返回 ORM 实体，应返回 DTO 或响应模型；不要手动实例化，禁止在 Nest 代码中 new Service()；配置应使用 @nestjs/config 或类型化配置层，而非散落的 process.env；DB 仓库、队列与客户端应注册进模块图，而非手动创建。资料未提供具体版本要求、安装命令或价格信息。