7.7 KiB
7.7 KiB
Prompt - 拆分Salesforce元数据拉取和部署子需求
输入引用
引用相关的 docs 文档链接：
- REQ-010.md - Salesforce元数据拉取和部署主需求文档
- Authentication.canvas - 项目架构视觉化展示
- 001-元数据模块设计 - 数据库设计和模块架构
- 002-元数据拉取参考网页地址 - 官方文档和开源项目参考
- 003-元数据拉取和部署数据库设计推荐 - 数据库设计推荐
- 004-元数据部署网页资料链接地址 - 部署相关参考资料
Context Maps
强制列出本次 Prompt 依赖的 Canvas 文件：
- Authentication.canvas - 项目架构视觉化展示
- 相关节点: 集成核心 - 提供与Salesforce的各种连接方式
- 相关节点: SessionManager - 会话管理，提供登录服务
- 相关节点: 集成任务 - 处理Salesforce的定时同步任务
- 相关节点: 通用常量 - Salesforce相关常量定义
目标
将 REQ-010 "Salesforce元数据拉取和部署" 需求拆分为多个可独立开发、测试和部署的子需求。每个子需求应该：
- 具有明确的范围和边界
- 可以独立完成并验证
- 遵循项目的现有架构和设计模式
- 具有清晰的依赖关系
- 包含完整的验收标准
输出格式
输出格式为 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 调用
- 必须遵循现有的异常处理机制
- 必须遵循现有的日志记录规范
拆分原则
- 独立性原则: 每个子需求应该可以独立开发、测试和部署
- 优先级原则: 优先拆分高优先级、低依赖的需求
- 粒度原则: 每个子需求的工作量控制在 3-5 人天
- 完整性原则: 每个子需求应该包含完整的 CRUD 操作
- 可测试性原则: 每个子需求应该有清晰的验收标准
建议的子需求拆分方向
基于 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: 性能优化和限流处理
验收标准
定义验证输出质量的具体标准：
- 完整性: 所有子需求必须覆盖 REQ-010 的所有功能点
- 独立性: 每个子需求应该可以独立开发和测试
- 可追溯性: 每个子需求必须能够追溯到 REQ-010 的具体需求项
- 可测试性: 每个子需求必须有清晰的验收标准
- 可行性: 每个子需求的工作量评估应该合理
- 依赖清晰: 子需求之间的依赖关系必须清晰明确
- 技术可行: 每个子需求的技术方案必须可行
- 符合架构: 每个子需求必须符合现有的项目架构
风险
识别使用此提示词可能带来的风险：
- 拆分粒度风险: 子需求拆分过细或过粗，影响开发效率
- 依赖关系风险: 子需求之间的依赖关系不清晰，导致开发阻塞
- 工作量评估风险: 工作量评估不准确，影响项目进度
- 技术方案风险: 某些子需求的技术方案可能存在技术难点
- 优先级风险: 子需求的优先级排序不合理，影响整体进度
使用指南
使用步骤
-
准备工作:
- 阅读 REQ-010.md 了解完整需求
- 阅读 Authentication.canvas 了解项目架构
- 阅读参考资料了解技术细节
-
拆分过程:
- 按照"建议的子需求拆分方向"进行拆分
- 为每个子需求填写完整的输出格式
- 确保每个子需求符合"拆分原则"
-
验证检查:
- 检查所有子需求是否覆盖 REQ-010 的所有功能点
- 检查每个子需求的验收标准是否清晰
- 检查子需求之间的依赖关系是否合理
- 检查工作量评估是否合理
-
输出结果:
- 生成完整的子需求拆分文档
- 保存为独立的 Markdown 文件（如
010-metadata-retrieve-deploy-sub-requirements.md）
注意事项
- 拆分时要考虑团队的技术能力和资源情况
- 优先拆分高优先级、低依赖的需求
- 每个子需求的工作量应该控制在 3-5 人天
- 子需求之间的依赖关系要尽量减少
- 每个子需求应该有明确的交付物
使用记录
| 日期 | 使用场景 | 输入参数 | 输出结果 | 反馈 | 改进措施 |
|---|---|---|---|---|---|
| 2026-01-17 | 拆分 REQ-010 子需求 | REQ-010.md, Authentication.canvas, 参考资料 | 生成子需求拆分文档 | - | - |