📝 docs(epic-007): 更新模块分析结果并重构故事结构

- 完成7个有实体模块的依赖关系分析，明确模块间依赖图谱
- 发现order与disability_person模块存在循环依赖问题
- 制定模块到独立包的映射方案，使用@d8d前缀和-module后缀命名
- 定义标准包结构规范，参考现有auth-module模式
- 提出循环依赖解决方案：创建共享实体包或接口抽象
- 更新故事结构，将原5个故事重构为4个，反映实际分析结果
- 调整移植顺序建议：platform → channel/dict/salary → company → order/disability
- 更新验证清单和故事经理交接说明，包含关键发现和注意事项

docs/epic-007.md

@@ -31,36 +31,165 @@
   3. 遵循现有独立包结构模式
   4. 通过类型检查和基本测试验证
 
-## 故事
-
-1. **故事1：分析模块结构和实体关系**
-   - 分析7个有实体模块的依赖关系
-   - 制定模块到独立包的映射方案
-   - 确定命名规范和包结构
-   - 验证实体与模块的对应关系
-
-2. **故事2：创建基础包模板和工具脚本**
-   - 创建标准的独立包模板
+## 模块分析结果
+
+### 1. 模块依赖关系分析
+
+根据对每个模块`module.ts`文件的分析，依赖关系如下：
+
+1. **channel_info模块** (`channel.module.ts`)
+   - 依赖：`@nestjs/common`, `@nestjs/typeorm`
+   - 实体：`Channel` (对应`channel_info`表)
+   - 无其他模块依赖
+
+2. **company模块** (`company.module.ts`)
+   - 依赖：`@nestjs/common`, `@nestjs/typeorm`, `PlatformModule`
+   - 实体：`Company` (对应`employer_company`表)
+   - 依赖模块：`platform`
+
+3. **dict_management模块** (`dict.module.ts`)
+   - 依赖：`@nestjs/common`, `@nestjs/typeorm`
+   - 实体：`Dict` (对应`sys_dict`表)
+   - 无其他模块依赖
+
+4. **disability_person模块** (`disability_person.module.ts`)
+   - 依赖：`@nestjs/common`, `@nestjs/typeorm`
+   - 实体：`DisabledPerson`, `DisabledBankCard`, `DisabledPhoto`, `DisabledRemark`, `DisabledVisit`
+   - 引用其他模块实体：`EmploymentOrder`, `OrderPerson` (order模块), `Platform` (platform模块), `Company` (company模块), `Channel` (channel_info模块)
+   - 复杂度：高（5个实体，多个控制器和服务）
+
+5. **order模块** (`order.module.ts`)
+   - 依赖：`@nestjs/common`, `@nestjs/typeorm`
+   - 实体：`EmploymentOrder`, `OrderPerson`, `OrderPersonAsset`
+   - 引用其他模块实体：`DisabledPerson` (disability_person模块), `Platform` (platform模块), `Company` (company模块), `Channel` (channel_info模块)
+   - 复杂度：中高（3个实体，跨模块依赖）
+
+6. **platform模块** (`platform.module.ts`)
+   - 依赖：`@nestjs/common`, `@nestjs/typeorm`
+   - 实体：`Platform` (对应`employer_platform`表)
+   - 无其他模块依赖
+   - 被依赖：`company`模块依赖此模块
+
+7. **salary模块** (`salary.module.ts`)
+   - 依赖：`@nestjs/common`, `@nestjs/typeorm`
+   - 实体：`SalaryLevel` (对应`salary_level`表)
+   - 无其他模块依赖
+
+### 2. 依赖关系图
+
+```
+platform ───┐
+            ↓
+company ────┐
+            ↓
+channel_info ─┐
+            ↓ ↓
+order ───────┘
+            ↑
+disability_person
+            ↑
+dict_management (独立)
+salary (独立)
+```
+
+**关键发现**：
+- `platform`模块是基础依赖，被`company`模块直接依赖
+- `company`、`channel_info`模块被`order`和`disability_person`模块引用
+- `order`和`disability_person`模块相互引用实体，形成循环依赖
+- `dict_management`和`salary`模块完全独立
+
+### 3. 模块到独立包的映射方案
+
+基于现有项目命名规范（参考`auth-module`、`file-module`等），制定以下映射方案：
+
+| 原模块名 | 独立包名 | 说明 |
+|---------|---------|------|
+| channel_info | `@d8d/channel-module` | 渠道管理模块 |
+| company | `@d8d/company-module` | 公司管理模块，依赖platform-module |
+| dict_management | `@d8d/dict-module` | 字典管理模块 |
+| disability_person | `@d8d/disability-module` | 残疾人管理模块（简化名称） |
+| order | `@d8d/order-module` | 订单管理模块 |
+| platform | `@d8d/platform-module` | 平台管理模块 |
+| salary | `@d8d/salary-module` | 薪资管理模块 |
+
+**命名原则**：
+1. 使用`@d8d/`作为包名前缀
+2. 模块名使用单数形式 + `-module`后缀
+3. 名称简洁明了，反映模块核心功能
+4. 不使用多租户后缀`-mt`（本次移植为非多租户版本）
+
+### 4. 包结构规范
+
+参考现有`auth-module`结构，每个独立包应包含：
+
+```
+packages/{module-name}/
+├── package.json          # 包配置，workspace依赖管理
+├── tsconfig.json        # TypeScript配置
+├── vitest.config.ts     # 测试配置（如需要）
+├── src/
+│   ├── index.ts         # 主导出文件
+│   ├── schemas/         # Zod模式定义（如需要）
+│   │   └── index.ts
+│   ├── entities/        # 数据库实体
+│   ├── services/        # 业务服务
+│   ├── controllers/     # API控制器
+│   ├── dtos/           # 数据传输对象
+│   └── types/          # TypeScript类型定义
+└── dist/               # 构建输出
+```
+
+**关键配置要求**：
+1. `package.json`中设置`"type": "module"`
+2. 主入口为`src/index.ts`
+3. 使用workspace依赖：`"@d8d/core-module": "workspace:*"`
+4. 导出必要的服务和实体
+
+### 5. 依赖关系解决方案
+
+针对发现的循环依赖问题（order ↔ disability_person），解决方案：
+
+1. **创建共享实体包**：将相互引用的实体提取到共享包
+2. **接口抽象**：使用接口而非具体实体引用
+3. **依赖注入调整**：重构服务层减少直接实体依赖
+4. **移植顺序策略**：按依赖顺序移植，先移植基础模块
+
+**建议移植顺序**：
+1. `platform-module`（基础）
+2. `channel-module`、`dict-module`、`salary-module`（独立）
+3. `company-module`（依赖platform）
+4. `order-module`和`disability-module`（最后处理，解决循环依赖）
+
+## 故事（更新后）
+
+**注**：故事1的分析工作已完成，结果见上方"模块分析结果"部分。
+
+1. **故事2：创建基础包模板和移植工具**
+   - 创建标准的独立包模板（参考auth-module结构）
    - 开发自动化移植脚本
    - 配置workspace依赖管理
    - 准备TypeScript配置和构建脚本
-
-3. **故事3：移植核心业务模块（company、platform、salary）**
-   - 移植公司管理模块（对应employer_company表）
-   - 移植平台管理模块（对应employer_platform表）
-   - 移植薪资管理模块（对应salary_level表）
-   - 验证功能完整性和数据一致性
-
-4. **故事4：移植复杂业务模块（order、disability_person）**
-   - 移植订单管理模块（对应employment_order、order_person、order_person_asset表）
-   - 移植残疾人管理模块（对应5个相关表）
-   - 验证复杂业务逻辑和关联关系
-
-5. **故事5：移植辅助模块（channel_info、dict_management）**
-   - 移植渠道信息模块（对应channel_info表）
-   - 移植字典管理模块（对应sys_dict表）
-   - 完成所有7个模块移植
-   - 整体功能验证和集成测试
+   - 创建package.json模板
+
+2. **故事3：移植基础独立模块**
+   - 移植`platform-module`（基础依赖）
+   - 移植`channel-module`（独立模块）
+   - 移植`dict-module`（独立模块）
+   - 移植`salary-module`（独立模块）
+   - 验证基础模块功能
+
+3. **故事4：移植依赖模块和解决循环依赖**
+   - 移植`company-module`（依赖platform-module）
+   - 处理`order-module`和`disability-module`的循环依赖
+   - 创建共享实体或接口抽象
+   - 移植两个复杂模块的核心功能
+
+4. **故事5：完成移植和集成验证**
+   - 完成所有7个模块的移植
+   - 解决剩余的依赖问题
+   - 进行整体功能验证
+   - 运行类型检查和基本测试
+   - 更新文档和配置
 
 ## 兼容性要求
 
@@ -77,7 +206,7 @@
 
 ## 完成定义
 
-- [ ] 所有5个故事完成，验收标准满足
+- [ ] 所有4个故事完成，验收标准满足
 - [ ] 现有功能通过测试验证
 - [ ] 集成点正常工作
 - [ ] 文档更新适当
@@ -86,7 +215,7 @@
 ## 验证清单
 
 ### 范围验证
-- [ ] 史诗可在5个故事内完成
+- [ ] 史诗可在4个故事内完成
 - [ ] 不需要架构文档变更
 - [ ] 增强遵循现有模式
 - [ ] 集成复杂度可管理
@@ -107,15 +236,20 @@
 
 ## 故事经理交接说明
 
-"请为此棕地史诗开发详细的用户故事。关键考虑：
+"模块分析已完成，关键发现：
+
+1. **依赖关系分析完成**：7个模块的依赖关系已明确，发现order和disability_person模块存在循环依赖
+2. **命名方案确定**：使用@d8d前缀，-module后缀，非多租户版本
+3. **移植顺序建议**：platform → channel/dict/salary → company → order/disability
+
+请基于以上分析开发详细的用户故事。关键考虑：
 
 - 这是对运行TypeScript、NestJS、PostgreSQL、Redis、MinIO的现有系统的增强
-- **只移植有实体的7个模块**：channel_info、company、dict_management、disability_person、order、platform、salary
-- **不移植的模块**：admin、auth、users（无对应数据库实体）
+- **只移植有实体的7个模块**，映射关系已确定
+- **循环依赖问题**：order和disability_person模块需要特殊处理
 - 集成点：模块间API调用、数据库访问、配置共享
 - 要遵循的现有模式：@d8d包命名、workspace依赖、模块化结构
 - 关键兼容性要求：API接口不变、数据库schema兼容、性能影响最小
 - 每个故事必须包含验证现有功能保持完整的检查
-- 特别注意disability_person和order模块的复杂实体关系
 
 史诗应在保持系统完整性的同时实现将有实体模块移植为标准化独立包的目标。"