用途：该技能用于设计并实现基于 NestJS 的可扩展模块化单体架构，结合 DDD、整洁架构与 CQRS 模式，从领域分析一路指导到生产可用实现，兼顾微服务的边界、独立性与可测试性，以及单体部署简单、共享基础设施、运维轻量的优势，并保留后续拆分为微服务的演进路径。
适用时机：从零设计模块化单体；定义限界上下文与领域边界；按整洁架构分层创建 NestJS 模块；搭建模块间事件驱动通信；在领域确有读写分离时可选引入 CQRS；规划单体到微服务的演进；用 NX 单仓工作区组织模块化后端；审查模块边界与状态隔离。
不适用：少于 10 个端点的简单 CRUD API；不以后端架构为重点的前端或全栈问题；缺少架构背景的一般 NestJS 问题；微服务优先架构；以速度优先于结构的原型或 MVP。
核心原则：模块间接口清晰、耦合最小；模块可组合；每个模块自包含；可按模块优化；通信契约显式；模块可替换；即便在单体中也保持逻辑部署分离；严格数据边界，不共享数据库表；模块级可观测；单模块故障不级联。
工作流程：发现阶段先理解业务领域、映射限界上下文、定义聚合与实体、明确扩展与集成需求，并确认技术栈偏好（HTTP 适配器 Fastify 或 Express、ORM 选 Prisma 或 TypeORM、API 风格 tRPC 或 REST+Swagger、单仓 NX 或 Turborepo、Lint 选 Biome 或 ESLint+Prettier、认证选 Passport/JWT 或 Better Auth、复杂度选简单服务或 CQRS）；设计阶段先输出架构文档，含模块图、通信图与数据模型；实现阶段按整洁架构分层顺序构建（领域、应用、基础设施、表现），跨模块仅通过事件或共享契约通信；验证阶段检查状态隔离、模块边界、测试覆盖、事件流转与构建图。
关键约束：所有服务使用依赖注入；输入用 DTO 与 class-validator 校验；仓储接口定义在领域层、实现在基础设施层；实体名加模块前缀；跨模块用事件通信；不得共享数据库表、不得直接导入其他模块内部服务、不得使用 any、不得产生循环依赖、不得用 Node.js EventEmitter 做生产级模块间通信、不得硬编码配置、不得对不需要的模块强加 CQRS。
本技能为咨询式架构与实现指南，未提供自身的安装命令或收费信息。