20 KiB
基础平台产品设计
1. 文档说明
1.1 文档目的
本文档用于定义基础平台的产品设计和业务需求，作为研发部门进行基础平台研发、测试部门进行测试验收的依据。
本文档重点描述基础平台需要支撑的业务对象、功能范围、业务规则、产品边界和验收标准，不描述具体技术实现方案。
1.2 阅读对象
- 研发部门：根据本文档理解基础平台的业务范围、功能模块、数据对象、业务规则和系统边界。
- 测试部门：根据本文档设计测试用例、验证功能完整性、业务规则正确性和跨模块协同结果。
- 产品部门：根据本文档进行需求澄清、范围控制、版本验收和后续迭代管理。
- 实施与交付团队：根据本文档理解基础平台能力边界和客户初始化配置方式。
1.3 建设背景
公司当前产品战略要求同时支撑纵向产品和横向产品：
- 纵向产品：营帐通拆分、连锁业务对账系统、分账系统、聚合支付系统、物流撮合行业分账试点。
- 横向产品：门店选址规划系统、连锁门店客服系统，以及后续餐饮连锁行业产品线。
为避免各业务系统重复建设组织、账号、权限、菜单、配置、消息、流程等通用能力，需要建设统一基础平台，作为后续多产品、多客户、多组织、多门店复用的底座。
1.4 版本范围
本文档定义基础平台 1.0 范围。
1.0 重点支撑：
- 多客户管理
- 组织管理
- 用户与账号管理
- 单点登录服务
- 统一 Token 认证鉴权
- 统一门户与菜单聚合
- 应用 iframe 容器
- 角色与权限管理
- 菜单与应用入口管理
- 基础配置管理
- 操作日志
- 消息与待办基础能力
- 基础数据字典
- 业务系统接入管理
1.0 不展开：
- 复杂工作流引擎
- 复杂主数据治理平台
- 数据中台
- 统一报表平台
- 复杂低代码配置平台
- 复杂开放平台能力
2. 产品定位
2.1 基础平台定位
基础平台是公司各业务产品的统一底座，为连锁业务对账系统、分账系统、聚合支付系统、门店选址规划系统、门店大数据平台、连锁门店客服系统等产品提供通用管理能力。
基础平台不直接承载具体业务交易，不负责对账、分账、支付、客服、选址等具体业务逻辑。基础平台负责统一管理业务系统运行所需的基础对象和通用能力。
2.2 核心价值
- 统一客户、组织、用户、角色、权限、菜单等基础能力。
- 支撑多产品复用，避免每个业务系统重复建设基础模块。
- 支撑多客户、多品牌、多门店、多业务系统的统一管理。
- 为后续分账系统 SaaS 化、聚合支付接入、客户项目交付提供基础能力。
- 为研发技术架构调整提供清晰的业务边界和模块边界。
2.3 产品边界
基础平台负责：
- 客户管理
- 组织管理
- 用户账号管理
- 单点登录服务
- 统一 Token 认证鉴权
- 统一门户与菜单聚合
- 应用 iframe 容器
- 角色权限管理
- 菜单与应用入口管理
- 基础配置管理
- 消息与待办基础能力
- 操作日志
- 数据字典
- 业务系统接入管理
基础平台不负责：
- 对账业务规则
- 分账业务规则
- 聚合支付业务规则
- 客服工单业务规则
- 选址评分模型
- 经营分析指标计算
- 具体客户项目的业务审批细节
3. 用户与使用场景
3.1 主要用户角色
| 角色 | 使用场景 |
|---|---|
| 平台超级管理员 | 管理客户、系统应用、全局配置、平台级账号 |
| 客户管理员 | 管理本客户下组织、用户、角色、权限、菜单 |
| 产品管理员 | 管理某个业务产品的菜单、权限项、接入配置 |
| 实施人员 | 初始化客户组织、账号、权限、配置 |
| 客服 / 运维人员 | 查询账号、权限、日志、消息状态，协助排查问题 |
| 业务系统用户 | 通过基础平台获得账号、权限、菜单、消息和待办 |
3.2 典型使用场景
3.2.1 新客户初始化
实施人员为新客户创建客户档案，配置客户基本信息，初始化组织架构、管理员账号、基础角色和可用应用。
3.2.2 新产品接入
产品管理员将新业务系统注册到基础平台，配置应用入口、菜单、权限项和可授权范围。
3.2.3 客户开通业务产品
平台管理员为客户开通连锁业务对账系统、分账系统、聚合支付等业务产品，客户管理员再给本客户内部用户分配权限。
3.2.4 用户登录与权限控制
用户登录后，根据所属客户、组织、角色和权限，看到对应业务系统入口和菜单，并只能操作授权范围内的数据。
3.2.5 账号和权限问题排查
客服或运维人员可查询用户所属组织、角色、权限、菜单、登录状态和操作日志，用于定位用户无法访问或权限异常问题。
4. 核心业务对象
4.1 对象清单
| 对象 | 定义 | 说明 |
|---|---|---|
| 客户 | 使用公司产品的企业或平台客户 | 例如餐饮连锁客户、鞋服连锁客户、物流撮合平台客户 |
| 应用 | 接入基础平台的业务系统 | 例如连锁业务对账系统、分账系统、聚合支付 |
| 组织 | 客户内部管理结构 | 例如总部、品牌、区域、门店、部门 |
| 用户 | 使用系统的自然人 | 可属于一个或多个组织 |
| 账号 | 用户登录系统的身份标识 | 与用户关联 |
| 登录会话 | 用户登录后形成的访问状态 | 用于支撑跨应用访问 |
| Token | 用户访问应用和接口的认证凭证 | 由基础平台统一签发和校验 |
| 门户框架 | 基础平台统一页面框架 | 包含头部、左侧菜单、Tab、内容区 |
| 应用入口 | 业务应用在基础平台中的访问入口 | 可指向基础平台页面或 iframe 应用页面 |
| 已打开页签 | 用户在门户中打开的页面 Tab | 可关联基础平台页面或业务应用页面 |
| iframe 容器 | 基础平台承载业务应用页面的容器 | 用于嵌入业务应用界面 |
| 角色 | 权限集合 | 例如客户管理员、财务主管、门店店长 |
| 权限项 | 系统可控制的功能或操作 | 例如查看、创建、修改、审核、导出 |
| 菜单 | 用户可见的系统导航入口 | 与应用和权限关联 |
| 数据范围 | 用户可查看或操作的数据边界 | 例如全部、指定组织、指定门店 |
| 配置项 | 可被客户或系统配置的参数 | 例如启用状态、业务开关 |
| 消息 | 系统向用户发送的通知 | 可包含待办、通知、提醒 |
| 操作日志 | 用户在系统中的关键操作记录 | 用于审计和排查 |
4.2 对象关系
- 一个客户可开通多个应用。
- 一个客户下可建立多级组织。
- 一个用户归属于一个客户。
- 一个用户可关联多个组织，但必须有一个默认组织。
- 一个用户可拥有多个角色。
- 一个用户登录基础平台后，可在已授权应用之间进行单点访问。
- 各业务应用访问时，Token 认证鉴权统一由基础平台完成。
- 基础平台统一聚合所有应用菜单。
- 业务应用不再独立渲染系统级菜单。
- 业务应用页面通过 iframe 方式嵌入基础平台内容区。
- 一个角色可包含多个权限项。
- 一个权限项归属于一个应用。
- 一个菜单归属于一个应用，并可绑定权限项。
- 一个用户最终可访问的菜单和功能，由客户开通应用、用户角色、权限项和数据范围共同决定。
5. 功能模块设计
基础平台功能模块详细设计已拆分至独立文档，便于研发、测试和产品分别按模块评审、开发和验收。
功能模块目录：功能模块
| 编号 | 功能模块 | 独立文档 |
|---|---|---|
| 5.1 | 客户管理 | 01-客户管理.md |
| 5.2 | 应用管理 | 02-应用管理.md |
| 5.3 | 组织管理 | 03-组织管理.md |
| 5.4 | 用户与账号管理 | 04-用户与账号管理.md |
| 5.5 | 单点登录与统一认证鉴权 | 05-单点登录与统一认证鉴权.md |
| 5.6 | 统一门户与应用容器 | 06-统一门户与应用容器.md |
| 5.7 | 角色管理 | 07-角色管理.md |
| 5.8 | 权限管理 | 08-权限管理.md |
| 5.9 | 菜单管理 | 09-菜单管理.md |
| 5.10 | 基础配置管理 | 10-基础配置管理.md |
| 5.11 | 消息与待办 | 11-消息与待办.md |
| 5.12 | 操作日志 | 12-操作日志.md |
| 5.13 | 数据字典 | 13-数据字典.md |
6. 跨模块业务规则
6.1 多客户隔离
- 所有客户数据必须隔离。
- 用户只能访问所属客户数据。
- 平台管理员可管理多个客户。
- 客户管理员只能管理本客户。
6.2 应用开通与访问
- 客户未开通应用时，该客户用户不可访问应用。
- 应用停用时，所有客户均不可访问。
- 用户是否能访问应用，由客户开通状态和用户角色共同决定。
6.3 权限生效顺序
用户最终权限由以下条件共同决定：
- 客户是否启用。
- 用户是否启用。
- 应用是否启用。
- 客户是否开通应用。
- Token 是否有效。
- 用户是否拥有对应角色。
- 角色是否包含对应权限。
- 数据范围是否覆盖目标数据。
任一条件不满足，用户不可访问对应功能或数据。
6.4 历史数据处理
- 客户、组织、用户、角色停用后，不删除历史数据。
- 历史操作日志保留。
- 历史业务数据归属不因组织调整自动变化。
7. 与业务系统关系
7.1 与营帐通现状关系
营帐通作为现有产品和客户项目现状，不作为基础平台 1.0 的新接入应用。
营帐通拆分后的目标产品为连锁业务对账系统和分账系统。基础平台 1.0 面向拆分后的连锁业务对账系统、分账系统提供客户、组织、用户、角色、菜单、权限、日志等能力。
营帐通现有业务能力、现状问题和迁移策略不在基础平台中处理，应在营帐通现状文档、连锁业务对账系统规划文档和分账系统规划文档中分别承接。
7.2 与连锁业务对账系统关系
基础平台提供用户、权限、组织、菜单、配置等能力。
连锁业务对账系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
连锁业务对账系统页面通过 iframe 嵌入基础平台内容区，不再独立渲染系统级菜单。
连锁业务对账系统负责对账任务、账单、流水、差异、报表等业务能力。
7.3 与分账系统关系
基础平台提供用户、权限、组织、菜单、配置等能力。
分账系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
分账系统页面通过 iframe 嵌入基础平台内容区，不再独立渲染系统级菜单。
分账系统负责结算主体、账户体系、分账规则、清分、分账、退款、出款等业务能力。
7.4 与聚合支付关系
基础平台提供用户、权限、应用入口、配置等能力。
聚合支付系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
聚合支付系统页面通过 iframe 嵌入基础平台内容区，不再独立渲染系统级菜单。
聚合支付系统负责支付渠道、支付订单、支付流水、退款、支付状态、支付通知等业务能力。
7.5 与客服系统关系
基础平台提供用户、组织、角色、权限、菜单、消息等能力。
客服系统用户登录、Token 认证和访问鉴权统一通过基础平台完成。
客服系统页面通过 iframe 嵌入基础平台内容区，不再独立渲染系统级菜单。
客服系统负责客诉、咨询、工单、补偿、回访、责任归属等业务能力。
8. 测试验收要求
8.1 测试范围
测试部门需重点覆盖：
- 客户隔离
- 组织管理
- 用户账号管理
- 单点登录
- Token 认证鉴权
- 统一门户布局
- 菜单聚合
- iframe 应用嵌入
- Tab 与 keepalive
- Token 共享与有效期管理
- 角色权限管理
- 菜单展示控制
- 应用开通控制
- 数据范围控制
- 配置项维护
- 消息与待办
- 操作日志
- 停用规则
- 多角色权限合并
8.2 核心测试场景
8.2.1 客户隔离测试
- A 客户用户不能看到 B 客户组织、用户、角色、菜单、日志。
- A 客户停用后，A 客户用户不可登录。
- B 客户不受 A 客户停用影响。
8.2.2 应用开通测试
- 未开通应用的客户不可见应用入口。
- 开通应用后，客户管理员可为用户授权。
- 应用停用后，所有客户均不可访问该应用。
8.2.3 角色权限测试
- 用户分配角色后可访问对应菜单和操作。
- 移除角色后权限失效。
- 多角色用户权限为授权能力组合。
- 无权限用户不可通过直接访问地址绕过权限。
8.2.4 单点登录与 Token 认证鉴权测试
- 用户登录基础平台后，可进入已授权业务应用。
- 用户未登录时，不可访问基础平台门户和业务应用。
- 用户访问未授权应用时，被拒绝访问。
- 用户访问业务应用入口时，统一进入基础平台门户登录和访问流程。
- Token 无效时，业务应用拒绝访问。
- Token 过期时，业务应用拒绝访问。
- Token 即将过期或已过期但允许刷新时，由基础平台门户统一刷新 Token。
- Token 刷新成功后，已打开 iframe 应用使用新 Token 继续访问。
- Token 刷新失败后，基础平台门户引导用户重新登录。
- 用户退出登录后，原访问状态失效。
- 用户在基础平台注销后，再访问其他应用时需要重新认证。
- 用户停用后，业务应用认证鉴权不通过。
- 客户停用后，该客户下用户认证鉴权不通过。
- 应用停用后，所有用户不可访问该应用。
- 所有接入应用均通过基础平台完成 Token 认证鉴权。
8.2.5 当前登录用户信息测试
- 业务应用可通过基础平台 Token 获取当前登录用户信息。
- 当前用户信息包含用户、客户、默认组织、组织列表、角色、可访问应用、菜单、操作权限和数据范围。
- 用户切换组织后，业务应用获取到的当前组织和数据范围正确。
- 用户权限变更后，业务应用重新获取用户信息时权限结果正确。
- Token 无效时，不可获取当前用户信息。
8.2.6 统一门户与 iframe 应用容器测试
- 基础平台主页面包含头部、左侧菜单导航栏和右侧内容区。
- 头部第一部分展示应用 logo、平台名称、菜单折叠按钮、常用菜单、主题设置、消息按钮、语言切换按钮、用户信息。
- 头部第二部分展示已打开页面 Tab 导航栏。
- 左侧菜单展示用户有权限访问的所有应用菜单。
- 用户无权限应用不展示菜单。
- 用户无权限菜单不展示。
- 点击基础平台菜单后，在右侧内容区打开基础平台页面。
- 点击业务应用菜单后，在右侧内容区通过 iframe 打开业务应用页面。
- 业务应用页面不展示自身系统级菜单。
- 打开页面后生成对应 Tab。
- 切换 Tab 时已打开页面状态保持。
- 关闭 Tab 后对应页面状态释放。
- 刷新当前 Tab 时仅刷新当前页面。
- 多个已打开 iframe 应用共享基础平台登录态。
- Token 刷新后，已打开 iframe 应用可继续访问。
- Token 失效或用户注销后，已打开 iframe 应用不可继续访问。
8.2.7 数据范围测试
- 本组织用户只能访问本组织数据。
- 本组织及下级组织用户可访问本组织和下级组织数据。
- 指定组织权限按指定范围生效。
- 不同客户之间数据不可跨越。
8.2.8 停用规则测试
- 停用客户后，客户下用户不可登录。
- 停用组织后，不可继续分配给新用户。
- 停用用户后，用户不可登录。
- 停用角色后，不可继续分配。
- 停用菜单后，用户不可见。
8.2.9 日志测试
- 新增、修改、删除、启用、停用、授权、配置变更等关键操作生成日志。
- 日志记录操作人、时间、对象、结果。
- 日志按客户隔离。
9. 验收清单
| 模块 | 验收项 | 是否必须 |
|---|---|---|
| 客户管理 | 支持客户新增、编辑、停用、客户编码生成、客户类型、所属行业、应用开通、客户管理员维护 | 是 |
| 应用管理 | 支持应用新增、编辑、启停、入口配置、菜单配置、权限项配置、可授权范围配置、已开通客户查看 | 是 |
| 组织管理 | 支持多级组织树和组织停用 | 是 |
| 用户管理 | 支持用户、账号、组织、角色维护 | 是 |
| 单点登录 | 支持一次登录访问多个已授权应用 | 是 |
| Token 认证鉴权 | 所有应用 Token 认证鉴权均通过基础平台完成 | 是 |
| Token 刷新 | 支持基础平台门户统一刷新 Token 并同步给已打开 iframe 应用 | 是 |
| 登录注销 | 用户注销后原 Token 不可继续访问应用 | 是 |
| 当前用户信息 | 支持业务应用通过 Token 获取当前登录用户信息 | 是 |
| 统一门户 | 支持头部、左侧菜单、Tab、右侧内容区布局 | 是 |
| 菜单聚合 | 支持聚合展示所有授权应用菜单 | 是 |
| iframe 应用容器 | 支持业务应用 iframe 嵌入基础平台内容区 | 是 |
| Tab 与 keepalive | 支持已打开页面 Tab 管理和状态保持 | 是 |
| Token 共享 | 支持已打开 iframe 应用共享基础平台 Token | 是 |
| 角色管理 | 支持角色授权和数据范围配置 | 是 |
| 权限管理 | 支持应用、菜单、操作、数据范围控制 | 是 |
| 菜单管理 | 支持菜单层级、排序、启停和权限绑定 | 是 |
| 配置管理 | 支持平台、客户、应用配置 | 是 |
| 消息待办 | 支持消息查询、已读未读、待办跳转 | 是 |
| 操作日志 | 支持关键操作记录和查询 | 是 |
| 多客户隔离 | 客户数据不可互相访问 | 是 |
| 停用规则 | 客户、组织、用户、角色、菜单停用规则正确 | 是 |
10. 后续迭代方向
基础平台 1.0 完成后，后续可按业务需要迭代：
- 更完整的流程审批能力
- 更完整的主数据管理能力
- 更细的数据权限模型
- 外部客户自助开通能力
- 开放平台和第三方接入能力
- 统一通知中心
- 更完整的审计与风控能力
- 统一首页和工作台
- 外部协同单点登录接入
上述能力不纳入 1.0 必须范围。
11. 2.0 版本规划补充
11.1 外部协同单点登录接入
基础平台 2.0 需要支持外部协同场景下的单点登录接入，使外部合作方、客户已有系统或第三方协同平台能够按规则接入基础平台认证体系。
2.0 重点支持：
- 外部系统单点登录接入
- 外部协同用户身份识别
- 外部用户与内部客户、组织、角色的映射关系
- 外部协同应用访问授权
- 外部协同登录状态管理
- 外部接入审计与日志
2.0 业务目标：
- 支持客户已有系统与公司业务系统之间的协同登录。
- 支持外部合作方访问被授权的业务应用。
- 保证外部协同用户访问仍受基础平台客户、组织、角色、权限、数据范围控制。
2.0 不在基础平台 1.0 范围内，研发和测试在 1.0 阶段只需预留产品边界认知，不作为 1.0 验收项。