|
|
@@ -0,0 +1,121 @@
|
|
|
+# 史诗007 - Allin System有实体模块移植到独立包
|
|
|
+
|
|
|
+## 史诗目标
|
|
|
+
|
|
|
+将allin_system-master/server/src目录下有对应数据库实体的模块移植到packages目录下，作为非多租户独立包，遵循项目现有的独立包结构和命名规范，实现模块的现代化重构和标准化管理。
|
|
|
+
|
|
|
+## 史诗描述
|
|
|
+
|
|
|
+### 现有系统上下文
|
|
|
+
|
|
|
+- **当前相关功能**：allin_system-master是一个基于NestJS的后端系统，根据allin_2025-11-25.sql分析，有以下有实体的模块：
|
|
|
+ 1. channel_info模块 - 对应channel_info表
|
|
|
+ 2. company模块 - 对应employer_company表
|
|
|
+ 3. dict_management模块 - 对应sys_dict表
|
|
|
+ 4. disability_person模块 - 对应disabled_person、disabled_bank_card、disabled_photo、disabled_remark、disabled_visit表
|
|
|
+ 5. order模块 - 对应employment_order、order_person、order_person_asset表
|
|
|
+ 6. platform模块 - 对应employer_platform表
|
|
|
+ 7. salary模块 - 对应salary_level表
|
|
|
+
|
|
|
+- **无实体模块（本次不移植）**：admin、auth、users模块
|
|
|
+- **技术栈**：TypeScript、NestJS、PostgreSQL、Redis、MinIO
|
|
|
+- **集成点**：模块间通过NestJS模块系统集成，共享数据库连接和配置
|
|
|
+
|
|
|
+### 增强详情
|
|
|
+
|
|
|
+- **新增/变更内容**：将7个有实体的现有模块从allin_system-master/server/src移植到packages目录下的独立包
|
|
|
+- **集成方式**：每个模块将重构为独立的npm包，遵循@d8d命名规范，通过workspace依赖管理
|
|
|
+- **成功标准**：
|
|
|
+ 1. 7个有实体模块成功移植为独立包
|
|
|
+ 2. 保持原有功能完整性
|
|
|
+ 3. 遵循现有独立包结构模式
|
|
|
+ 4. 通过类型检查和基本测试验证
|
|
|
+
|
|
|
+## 故事
|
|
|
+
|
|
|
+1. **故事1：分析模块结构和实体关系**
|
|
|
+ - 分析7个有实体模块的依赖关系
|
|
|
+ - 制定模块到独立包的映射方案
|
|
|
+ - 确定命名规范和包结构
|
|
|
+ - 验证实体与模块的对应关系
|
|
|
+
|
|
|
+2. **故事2：创建基础包模板和工具脚本**
|
|
|
+ - 创建标准的独立包模板
|
|
|
+ - 开发自动化移植脚本
|
|
|
+ - 配置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个模块移植
|
|
|
+ - 整体功能验证和集成测试
|
|
|
+
|
|
|
+## 兼容性要求
|
|
|
+
|
|
|
+- [ ] 现有API接口保持不变
|
|
|
+- [ ] 数据库schema保持向后兼容
|
|
|
+- [ ] 遵循现有TypeScript配置和构建模式
|
|
|
+- [ ] 性能影响最小化
|
|
|
+
|
|
|
+## 风险缓解
|
|
|
+
|
|
|
+- **主要风险**：模块间依赖关系复杂，移植过程中可能破坏现有功能
|
|
|
+- **缓解措施**：逐个模块移植，每个模块完成后进行功能验证
|
|
|
+- **回滚计划**：保留原始allin_system-master目录作为备份，可随时恢复
|
|
|
+
|
|
|
+## 完成定义
|
|
|
+
|
|
|
+- [ ] 所有5个故事完成，验收标准满足
|
|
|
+- [ ] 现有功能通过测试验证
|
|
|
+- [ ] 集成点正常工作
|
|
|
+- [ ] 文档更新适当
|
|
|
+- [ ] 现有功能无回归
|
|
|
+
|
|
|
+## 验证清单
|
|
|
+
|
|
|
+### 范围验证
|
|
|
+- [ ] 史诗可在5个故事内完成
|
|
|
+- [ ] 不需要架构文档变更
|
|
|
+- [ ] 增强遵循现有模式
|
|
|
+- [ ] 集成复杂度可管理
|
|
|
+
|
|
|
+### 风险评估
|
|
|
+- [ ] 对现有系统风险较低
|
|
|
+- [ ] 回滚计划可行
|
|
|
+- [ ] 测试方法覆盖现有功能
|
|
|
+- [ ] 团队对集成点有足够了解
|
|
|
+
|
|
|
+### 完整性检查
|
|
|
+- [ ] 史诗目标清晰可实现
|
|
|
+- [ ] 故事范围适当
|
|
|
+- [ ] 成功标准可衡量
|
|
|
+- [ ] 依赖关系已识别
|
|
|
+
|
|
|
+---
|
|
|
+
|
|
|
+## 故事经理交接说明
|
|
|
+
|
|
|
+"请为此棕地史诗开发详细的用户故事。关键考虑：
|
|
|
+
|
|
|
+- 这是对运行TypeScript、NestJS、PostgreSQL、Redis、MinIO的现有系统的增强
|
|
|
+- **只移植有实体的7个模块**：channel_info、company、dict_management、disability_person、order、platform、salary
|
|
|
+- **不移植的模块**：admin、auth、users（无对应数据库实体）
|
|
|
+- 集成点：模块间API调用、数据库访问、配置共享
|
|
|
+- 要遵循的现有模式：@d8d包命名、workspace依赖、模块化结构
|
|
|
+- 关键兼容性要求：API接口不变、数据库schema兼容、性能影响最小
|
|
|
+- 每个故事必须包含验证现有功能保持完整的检查
|
|
|
+- 特别注意disability_person和order模块的复杂实体关系
|
|
|
+
|
|
|
+史诗应在保持系统完整性的同时实现将有实体模块移植为标准化独立包的目标。"
|
yourname