201 lines
7.7 KiB
Markdown
201 lines
7.7 KiB
Markdown
# Prompt - 拆分Salesforce元数据拉取和部署子需求
|
||
|
||
## 输入引用
|
||
|
||
引用相关的 docs 文档链接：
|
||
|
||
- [REQ-010.md](../requirements/REQ-010.md) - Salesforce元数据拉取和部署主需求文档
|
||
- [Authentication.canvas](../Authentication.canvas) - 项目架构视觉化展示
|
||
- [001-元数据模块设计](../reference-code/metadata/001-元数据模块设计) - 数据库设计和模块架构
|
||
- [002-元数据拉取参考网页地址](../reference-code/metadata/002-元数据拉取参考网页地址) - 官方文档和开源项目参考
|
||
- [003-元数据拉取和部署数据库设计推荐](../reference-code/metadata/003-元数据拉取和部署数据库设计推荐) - 数据库设计推荐
|
||
- [004-元数据部署网页资料链接地址](../reference-code/metadata/004-元数据部署网页资料链接地址) - 部署相关参考资料
|
||
|
||
## Context Maps
|
||
|
||
强制列出本次 Prompt 依赖的 Canvas 文件：
|
||
|
||
- [Authentication.canvas](../Authentication.canvas) - 项目架构视觉化展示
|
||
- **相关节点**: [集成核心](node_integration_core) - 提供与Salesforce的各种连接方式
|
||
- **相关节点**: [SessionManager](node_session_manager_detail) - 会话管理，提供登录服务
|
||
- **相关节点**: [集成任务](node_integration_task) - 处理Salesforce的定时同步任务
|
||
- **相关节点**: [通用常量](node_common_constant) - Salesforce相关常量定义
|
||
|
||
## 目标
|
||
|
||
将 REQ-010 "Salesforce元数据拉取和部署" 需求拆分为多个可独立开发、测试和部署的子需求。每个子需求应该：
|
||
- 具有明确的范围和边界
|
||
- 可以独立完成并验证
|
||
- 遵循项目的现有架构和设计模式
|
||
- 具有清晰的依赖关系
|
||
- 包含完整的验收标准
|
||
|
||
## 输出格式
|
||
|
||
输出格式为 Markdown 文档，每个子需求包含以下结构：
|
||
|
||
```markdown
|
||
## 子需求 N: [子需求名称]
|
||
|
||
### 需求信息
|
||
- **子需求编号**: REQ-010-N
|
||
- **父需求**: REQ-010
|
||
- **需求类型**: [功能需求 | 数据需求 | 接口需求]
|
||
- **优先级**: [高 | 中 | 低]
|
||
- **预计工作量**: [人天]
|
||
|
||
### 需求描述
|
||
简要描述子需求的目标和范围
|
||
|
||
### 功能范围
|
||
列出子需求包含的具体功能点
|
||
|
||
### 验收标准
|
||
列出具体的验收标准，每个标准应该是可测试的
|
||
|
||
### 依赖关系
|
||
- **前置依赖**: 列出依赖的其他子需求
|
||
- **被依赖**: 列出依赖此子需求的其他子需求
|
||
|
||
### 技术要点
|
||
列出实现此子需求需要关注的技术点
|
||
|
||
### 数据库设计
|
||
列出需要创建或修改的数据库表
|
||
|
||
### API接口
|
||
列出需要创建或修改的API接口
|
||
|
||
### 风险点
|
||
列出实现此子需求可能遇到的风险
|
||
```
|
||
|
||
## 约束
|
||
|
||
- **技术栈限制**: 必须基于现有的 Spring Boot 3 + Vue 3 技术栈
|
||
- **架构约束**: 必须遵循 Authentication.canvas 中定义的架构和调用关系
|
||
- **模块约束**: 必须在 `datai-salesforce-metadata` 模块下实现
|
||
- **数据库约束**: 必须使用 MyBatis Plus 作为持久层框架
|
||
- **认证约束**: 必须使用现有的认证模块和 SessionManager 进行会话管理
|
||
- **API约束**: 必须使用现有的集成核心功能进行 Salesforce API 调用
|
||
- **文档约束**: 每个子需求必须遵循 REQ-010 中定义的验收标准
|
||
- **依赖约束**: 子需求之间的依赖关系必须清晰，避免循环依赖
|
||
|
||
## Rule Set
|
||
|
||
"请严格参考 @Authentication.canvas 中的状态机转移逻辑，不要自行发挥。"
|
||
|
||
**具体规则**：
|
||
- 必须使用 Canvas 中定义的类名和方法名
|
||
- 必须遵循 Canvas 中定义的调用关系
|
||
- 必须参考 Canvas 中的流程图逻辑
|
||
- 必须使用 SessionManager 进行会话管理和自动重新登录
|
||
- 必须使用现有的认证模块进行 OAuth 认证
|
||
- 必须使用现有的集成核心功能进行 API 调用
|
||
- 必须遵循现有的异常处理机制
|
||
- 必须遵循现有的日志记录规范
|
||
|
||
## 拆分原则
|
||
|
||
1. **独立性原则**: 每个子需求应该可以独立开发、测试和部署
|
||
2. **优先级原则**: 优先拆分高优先级、低依赖的需求
|
||
3. **粒度原则**: 每个子需求的工作量控制在 3-5 人天
|
||
4. **完整性原则**: 每个子需求应该包含完整的 CRUD 操作
|
||
5. **可测试性原则**: 每个子需求应该有清晰的验收标准
|
||
|
||
## 建议的子需求拆分方向
|
||
|
||
基于 REQ-010 的 7 个详细需求，建议按以下方向拆分：
|
||
|
||
### 方向 1: 基础设施层（优先级：高）
|
||
- 子需求 1: 数据库表结构设计和创建
|
||
- 子需求 2: 基础实体类和 Mapper 创建
|
||
|
||
### 方向 2: 配置管理层（优先级：高）
|
||
- 子需求 3: Salesforce 组织配置管理
|
||
- 子需求 4: 元数据任务定义管理
|
||
|
||
### 方向 3: 元数据拉取层（优先级：高）
|
||
- 子需求 5: Metadata API 客户端封装
|
||
- 子需求 6: 元数据拉取核心功能
|
||
- 子需求 7: 文件存储和解压处理
|
||
|
||
### 方向 4: 元数据部署层（优先级：高）
|
||
- 子需求 8: 元数据部署核心功能
|
||
- 子需求 9: Quick Deploy 功能实现
|
||
- 子需求 10: Destructive Changes 功能实现
|
||
|
||
### 方向 5: 元数据管理层（优先级：中）
|
||
- 子需求 11: 元数据组件索引和查询
|
||
- 子需求 12: 文件哈希对比和增量检测
|
||
- 子需求 13: 版本回溯功能
|
||
|
||
### 方向 6: 监控和日志层（优先级：中）
|
||
- 子需求 14: 作业执行监控
|
||
- 子需求 15: 详细日志记录和查询
|
||
|
||
### 方向 7: 异常处理和优化（优先级：中）
|
||
- 子需求 16: 异常处理机制完善
|
||
- 子需求 17: 性能优化和限流处理
|
||
|
||
## 验收标准
|
||
|
||
定义验证输出质量的具体标准：
|
||
|
||
1. **完整性**: 所有子需求必须覆盖 REQ-010 的所有功能点
|
||
2. **独立性**: 每个子需求应该可以独立开发和测试
|
||
3. **可追溯性**: 每个子需求必须能够追溯到 REQ-010 的具体需求项
|
||
4. **可测试性**: 每个子需求必须有清晰的验收标准
|
||
5. **可行性**: 每个子需求的工作量评估应该合理
|
||
6. **依赖清晰**: 子需求之间的依赖关系必须清晰明确
|
||
7. **技术可行**: 每个子需求的技术方案必须可行
|
||
8. **符合架构**: 每个子需求必须符合现有的项目架构
|
||
|
||
## 风险
|
||
|
||
识别使用此提示词可能带来的风险：
|
||
|
||
1. **拆分粒度风险**: 子需求拆分过细或过粗，影响开发效率
|
||
2. **依赖关系风险**: 子需求之间的依赖关系不清晰，导致开发阻塞
|
||
3. **工作量评估风险**: 工作量评估不准确，影响项目进度
|
||
4. **技术方案风险**: 某些子需求的技术方案可能存在技术难点
|
||
5. **优先级风险**: 子需求的优先级排序不合理，影响整体进度
|
||
|
||
## 使用指南
|
||
|
||
### 使用步骤
|
||
|
||
1. **准备工作**:
|
||
- 阅读 REQ-010.md 了解完整需求
|
||
- 阅读 Authentication.canvas 了解项目架构
|
||
- 阅读参考资料了解技术细节
|
||
|
||
2. **拆分过程**:
|
||
- 按照"建议的子需求拆分方向"进行拆分
|
||
- 为每个子需求填写完整的输出格式
|
||
- 确保每个子需求符合"拆分原则"
|
||
|
||
3. **验证检查**:
|
||
- 检查所有子需求是否覆盖 REQ-010 的所有功能点
|
||
- 检查每个子需求的验收标准是否清晰
|
||
- 检查子需求之间的依赖关系是否合理
|
||
- 检查工作量评估是否合理
|
||
|
||
4. **输出结果**:
|
||
- 生成完整的子需求拆分文档
|
||
- 保存为独立的 Markdown 文件（如 `010-metadata-retrieve-deploy-sub-requirements.md`）
|
||
|
||
### 注意事项
|
||
|
||
- 拆分时要考虑团队的技术能力和资源情况
|
||
- 优先拆分高优先级、低依赖的需求
|
||
- 每个子需求的工作量应该控制在 3-5 人天
|
||
- 子需求之间的依赖关系要尽量减少
|
||
- 每个子需求应该有明确的交付物
|
||
|
||
## 使用记录
|
||
|
||
| 日期 | 使用场景 | 输入参数 | 输出结果 | 反馈 | 改进措施 |
|
||
|------|---------|---------|---------|------|----------|
|
||
| 2026-01-17 | 拆分 REQ-010 子需求 | REQ-010.md, Authentication.canvas, 参考资料 | 生成子需求拆分文档 | - | - |
|