# 03-产品管理范围内产品与产品需求链路与工作流方案 ## 0. 文档目的 本文档用于回答以下问题： - 在当前产品管理范围内，`product -> product_requirement` 是否适合做链路视图 - 后续工单进入产品侧时，应如何接入当前产品管理链路 - 是否适合引入 Flowable - Flowable 在当前产品管理方案中应承接哪些节点，不应承接哪些节点 - 当前产品管理链路应如何建模 - 当前产品需求设计中的“终态原因”口径适用范围是什么 说明： - 本文档中的“产品作为主上下文”仅限当前产品管理能力建设范围。 - 该口径用于当前产品管理方案收敛，不作为 RDMS 全局统一建模原则。 - 本文档只给方案，不直接修改业务代码、SQL 或正式设计文档。 ## 1. 当前现状判断 ### 1.1 当前代码与文档现状 - 当前仓库未看到 Flowable 依赖、BPMN 定义或流程引擎接入实现。 - `rdms-project` 已开始承接通用对象状态模型，当前已有 `rdms_object_status_model`、`rdms_object_status_transition` 的 DO 和 Mapper。 - 产品管理当前已经明确：产品与产品需求承接轻量状态流转，但当前版本不展开正式工作流引擎。 - 当前产品需求设计已具备来源追溯、状态流转、认领 / 拒绝、拆分等业务语义。 - 当前要开发的是产品管理，不是项目管理；`project_requirement / execution / task` 不属于本期范围。 ### 1.2 当前链路特征 在本期产品管理范围内，当前业务链路主要具备以下特征： - 产品是当前方案的主上下文 - 产品侧可以手工新增产品需求 - 后续工单可以进入产品侧形成来源需求 - 一个产品需求可以拆分成 N 个子需求 - 某些节点需要人认领、人评审、人审批 - 某些节点只是普通业务状态推进，不适合上审批流 这意味着在本期产品管理范围内，该链路本质上是“产品上下文下的产品需求关系网络”，不是“一条从头跑到尾的单一审批流程”。 ## 2. 核心结论 ### 2.1 可行性判断 结论：可行，但本期不建议把产品管理范围内的所有动作都堆进单一 Flowable 流程。 推荐方向： - 在本期产品管理方案内，产品作为当前链路的主上下文和主入口 - 当前链路聚合围绕 `product`、`product_requirement` 组织 - 需求链（`chain`）表示“本期产品管理范围内，产品下的一条源头需求链” - 工单在后续接入时，只作为产品需求的来源关系之一，不作为链路根 - 业务主链统一由状态机控制 - Flowable 等以后开发评审流程时再接入，只承接评审、审批类协同节点 - 各业务对象继续维护自己的 `status_code` - 流程状态不是业务真相源，业务表状态才是业务真相源 - 本期先按表和后端接口完成基础建模和后端闭环，不做前端页面和流程引擎接入 ### 2.2 不建议单一长流程的原因 - 产品需求存在手工新增、父子拆分等多种情况；后续再叠加工单来源时，也难以用单流程表达。 - 认领、拒绝、拆分、关闭等动作很多是高频业务动作，不适合全部流程化。 - 流程状态和业务状态容易双写不一致。 - 当前真正需要先打通的是产品管理范围内的后端聚合能力，而不是先上流程图。 ### 2.3 终态原因口径适用范围 “终态原因承接口径”不是只针对工单来源需求，而是针对产品需求对象本身。 也就是说，无论产品需求来自： - 工单流转 - 手工新增 只要走到 `reject`、`cancel`、`close` 这类终态动作，都需要明确终态原因承接方式。 从后端聚合查询角度看，主表保留当前结果态原因字段，审计日志继续保留完整留痕。 ## 3. 建议总体架构 当前建议拆成 4 层，再预留 1 个后续扩展层。 ### 3.1 业务对象层 业务对象继续独立建模，独立维护生命周期和 `status_code`。 本期纳入当前链路建模的对象： - 产品 `product` - 产品需求 `product_requirement` - `work_order` 作为后续预留来源对象 要求： - 在本期产品管理范围内，产品是当前链路的主上下文 - 产品需求是当前链路的核心业务对象 - 每个对象的状态变化由业务服务负责落库 - 后续工单进入产品侧后，只承接来源关系，不取代产品主上下文 - 业务主链先由状态机控制，不由流程引擎接管 ### 3.2 关系模型层 关系模型用于描述对象之间的连接关系，而不是靠单个来源字段硬扛全部追溯逻辑。 本期至少需要表达以下关系： - 产品和源头需求之间的主上下文关系 - 产品需求父子拆分 建议引入统一关系表，例如： `rdms_biz_relation` 建议关键字段： - `id` - `chain_id` - `product_id` - `from_biz_type` - `from_biz_id` - `to_biz_type` - `to_biz_id` - `relation_type` - `sort` - `remark` 建议 `relation_type` 取值至少包括： - `product_root`：产品主上下文 - `split_child`：拆分子需求 后续预留关系类型： - `source_work_order`：来源工单 说明： - `product_root` 用于表达本期产品管理范围内，产品和源头需求之间的主上下文关系。 - 手工新增不是对象间来源关系，不必强行补一条虚拟来源边；可由 `rdms_requirement_chain.entry_source_type = manual` 承接。 ### 3.3 事件模型层 事件模型用于描述“产品下的一条需求链上发生了什么”，服务于后端聚合查询和后续时间线视图。 建议引入统一事件表，例如： `rdms_biz_event` 建议关键字段： - `id` - `chain_id` - `product_id` - `biz_type` - `biz_id` - `event_type` - `action_code` - `from_status_code` - `to_status_code` - `operator_user_id` - `operator_name` - `reason` - `event_time` - `payload_json` 事件类型可覆盖： - `create` - `claim` - `reject` - `split` - `review_pass` - `review_reject` - `close` - `cancel` 后续预留事件类型： - `source_attach` ### 3.4 需求链聚合层 为了做当前产品管理范围内的链路聚合，建议引入统一聚合对象。 建议引入需求链主表，例如： `rdms_requirement_chain` 建议关键字段： - `id` - `chain_code` - `product_id` - `root_requirement_id` - `entry_source_type` - `entry_biz_type` - `entry_biz_id` - `title` - `current_status_code` - `closed_flag` 用途： - 作为“产品下的一条源头需求链”的聚合单元 - 聚合关系和事件 - 支撑后端聚合查询；后续前端如接入，再由产品详情页和产品需求详情页承接 说明： - 一个产品下会有多条需求链 - 一条需求链只属于一个产品 - 一条需求链只围绕一个源头产品需求展开 - 后续工单来源需求创建需求链时，工单只写入 `entry_biz_type / entry_biz_id` 和 `source_work_order` 关系，不作为根对象 ### 3.5 流程绑定层（后续扩展） 流程引擎只负责协同过程，因此等以后开发评审流程时，可再补业务对象和流程实例的绑定层。 建议引入流程绑定表，例如： `rdms_workflow_binding` 建议关键字段： - `id` - `chain_id` - `product_id` - `biz_type` - `biz_id` - `process_definition_key` - `process_instance_id` - `workflow_status` - `current_task_key` - `current_task_name` - `starter_user_id` - `start_time` - `end_time` 说明： - 该层不是本期前置条件 - 本期不接 Flowable 时，不需要先落这张表 - 等以后开发评审流程时再接入，只用于评审、审批类协同节点 ## 4. Flowable 适用边界 ### 4.1 适合接 Flowable 的节点 以下节点等以后开发评审流程时，可考虑接入 Flowable： - 产品需求待评审 - 高风险终态动作审批 - 其他明确的审批类节点 这类节点的共同特征是： - 需要明确待办人 - 需要审批意见 - 需要驳回、转交、加签、会签等协作能力 ### 4.2 不建议接 Flowable 的节点 以下节点不建议直接建成流程审批节点： - 后续工单接入产品侧后的认领 / 拒绝 - 普通状态编辑 - 列表筛选查询 - 日常状态推进 - 产品需求拆分 这类节点更适合保留在业务状态机或普通业务服务里，否则流程实例会过多、过碎、过重。 ## 5. 当前链路视图如何实现 本期只要求后端先具备聚合查询能力，不要求直接交付页面。 ### 5.1 拓扑数据 展示本期产品管理范围内，以产品为入口的对象关系链： ```text 产品 -> 产品需求（源头需求） -> 子需求 后续工单 -(source_work_order)-> 产品需求（可选来源） ``` 后端主要聚合： - `rdms_requirement_chain` - `rdms_biz_relation` - `product` - `product_requirement` ### 5.2 时间线数据 展示产品下某条需求链上的关键事件： - 产品需求创建 - 产品需求认领 - 产品需求评审 - 拆分子需求 - 关闭 / 拒绝 / 取消 后端主要聚合： - `rdms_biz_event` - `product_requirement` 当前状态摘要 说明： - 时间线围绕单条需求链展开，不是把整个产品下所有动作混成一条总流水。 - 本期先交付后端聚合查询接口，不要求同时交付拓扑页和时间线页，也不进入前端联调。 ## 6. 对现有产品管理设计的建议 ### 6.1 本期产品管理范围内的主上下文口径 既然本期要开发的是产品管理，建议当前方案中的聚合查询和后端入口都优先挂在产品上下文下。 要求： - `product_id` 是链路聚合模型的必填归属字段 - 后续前端如接入，产品详情页和产品需求详情页是主入口 - 后续工单详情页如需展示链路，只适合作为来源跳转入口，不适合作为主视图入口 ### 6.2 状态口径 既然你已经确认本期只做产品和产品需求，建议当前阶段只要求这两个对象继续沿用统一的 `status_code` 口径。 说明： - `product` - `product_requirement` 项目管理阶段再单独设计 `project_requirement / execution / task` 的状态模型和流转规则，不并入本期范围。 ### 6.3 来源与拆分口径 你已经确认： - 来源承接和需求拆分分开建模 - 后续工单来源需求可拆分 - 手工新增需求也可拆分 当前产品需求口径应将来源追溯和拆分关系分开承接： - `source_biz_*` 字段只承接来源追溯 - `parent_requirement_id`、`root_requirement_id` 承接拆分链路 - 后续同一产品下，同一来源工单只生成 1 条源头需求记录 - 子需求不参与来源唯一约束 ### 6.4 终态原因口径 产品需求主表统一承接当前结果态字段。 当前字段方向： - `terminal_action_code` - `terminal_reason` - `terminal_time` 这样后端做本期产品管理范围内的聚合查询时，可以直接读取当前结果态原因，而不用每次回扫审计日志。 ## 7. 建议实施顺序 建议按三步走，但只有第一步属于本期必做范围。 ### 第一步：先完成本期产品管理的基础建模和后端闭环 目标： - 明确在本期产品管理范围内，产品作为当前链路的主上下文 - 建立链路主表 - 建立链路关系表 - 建立链路事件表 - 统一产品和产品需求的状态口径 - 先把业务主链的状态机闭环跑通 - 先提供产品上下文下查询单条需求链关系拓扑和事件时间线的聚合接口 这一阶段先不接 Flowable，只按表和后端接口开发，不做前端拓扑页和时间线页，也不扩到项目管理对象。 ### 第二步：后续开发评审流程时接入有限流程节点 目标： - 产品需求评审 - 高风险终态审批 - 其他明确需要审批协同的节点 这类节点等以后开发评审流程时可接入 Flowable，但不是本期前置条件。 ### 第三步：后续在项目管理阶段扩展项目域对象 目标： - 在后续项目管理建设时，再补 `project_requirement / execution / task` 等对象 - 届时再单独设计它们和产品需求之间的关系、事件和流程边界 说明： - 这一步不属于本期产品管理开发范围。 ## 8. 风险点与控制建议 ### 8.1 范围扩散到项目管理 风险： - 在当前产品管理开发过程中，又把 `project_requirement / execution / task` 一起拉进来 控制建议： - 所有设计文档都明确“本期只做产品和产品需求” - 项目域对象放到后续项目管理建设时再单独设计 ### 8.2 状态双写不一致 风险： - 流程状态更新了，但业务表状态没更新 - 业务状态更新了，但流程实例没推进 控制建议： - 本期主链统一由状态机控制 - 等以后开发评审流程时接入 Flowable，也只作为协同触发器 - 每次关键动作统一写 `rdms_biz_event` ### 8.3 来源与拆分关系混淆 风险： - 来源关系和拆分关系混在一个字段里，后续追溯会失真 控制建议： - 来源关系和父子拆分关系分开建模 - 统一走关系表，不靠单字段隐式表达 ### 8.4 前端聚合过早介入 风险： - 后端模型和接口还没稳住，就先开始拼页面，后面会频繁返工 控制建议： - 本期先完成基础建模和聚合查询接口 - 前端页面放到后续接口稳定后再接入 ## 9. 当前建议结论 当前建议拍板如下： 1. 在本期产品管理方案内，产品作为当前链路的主上下文。 2. 本期范围只包含 `product`、`product_requirement`；`work_order` 只作为后续预留来源对象，不纳入第一批实现。 3. 一条需求链（`chain`）表示“产品下的一条源头需求链”，不是整个产品，也不是某个工单。 4. 本期先做基础建模和后端闭环，包括 `requirement_chain / relation / event` 模型、状态机主链、关键动作落库和聚合查询接口。 5. 本期主链统一由状态机控制；Flowable 等以后开发评审流程时再接入，只用于评审、审批类节点。 6. 来源追溯和需求拆分必须分开建模。 7. 产品需求终态原因由主表承接当前结果态，并继续保留审计日志完整留痕。 8. 项目域对象放到后续项目管理建设时再单独设计，不并入本期产品管理范围。 9. 以上口径仅用于当前产品管理建设，不作为 RDMS 全局统一建模原则。 ## 10. 下一步建议产物 如果继续推进，建议下一步补 3 份专项文档： 1. `产品管理范围内链路接口设计.md` 明确聚合查询接口、状态动作接口的返回结构。 2. `产品管理范围内链路SQL与表结构设计.md` 明确 `requirement_chain / relation / event` 的表结构和索引设计。 3. `产品管理范围内链路开发顺序与任务拆分.md` 明确 SQL、DO、Mapper、Service、Controller 的开发顺序。