用途：在单个可部署单元内组织代码，选择架构模式并诊断既有代码的架构问题，目标是让代码在编写 18 个月后仍可理解、测试和修改。不涉及微服务拆分、数据库模式设计、框架路由或 CI/CD。
主要能力：
- 选择架构模式：整洁架构、六边形架构（端口与适配器）、按功能组织、垂直切片。
- 诊断问题：胖控制器、循环依赖、业务逻辑纠缠。
- 应用依赖倒置解耦，设置依赖注入容器，定义模块边界与 barrel 导出。
- 按架构层设计测试金字塔。
关键原则：整洁架构依赖只能向内；实体不知用例，用例不知控制器，控制器不知数据库驱动。六边形架构中领域通过端口（接口）连接，适配器实现端口，便于替换基础设施。按功能组织时，features/X 内含 X 的全部层，通过 index.ts 暴露公共 API，功能间只从公共 API 导入。
反模式：控制器内写业务逻辑（应放入可脱离 HTTP 测试的用例）；为抽象而抽象（单一实现且不变的接口是仪式）；循环依赖（应合并模块、抽取共享模块、用接口倒置或事件驱动）。
检测命令：npx madge --circular src/；npx dpdm --circular src/index.ts；ESLint 规则 "import/no-cycle": "error"。
测试分层：实体用单元测试，用例用带 mock 的单元测试，适配器用集成测试，框架用 E2E/契约测试。业务逻辑测试不应启动服务器、连接数据库或发起网络调用。
限制：资料未提供具体收费、平台支持或安装步骤；DI 容器是否值得使用取决于依赖数量与手动装配成本。