802 lines
25 KiB
Markdown
802 lines
25 KiB
Markdown
# Continental Retail APP Architecture Diagram 详细说明
|
||
|
||
本文用于解释 `architecture-diagram.drawio` 中的 3 张系统架构图，帮助产品、研发、架构、移动端、后端、集成、测试和评审人员快速理解这套系统为什么这样设计、每一页分别在说明什么、不同域之间的关系如何划分，以及关键访问链路和治理规则如何落地。
|
||
|
||
这 3 张图不是数据库设计图，也不是接口字段定义图，更不是某台服务器部署细节图。它们的定位是：
|
||
|
||
- 用于统一架构认知。
|
||
- 用于评审系统边界和责任归属。
|
||
- 用于说明主访问链路和例外链路。
|
||
- 用于帮助研发和测试理解关键业务运行方式。
|
||
|
||
---
|
||
|
||
## 1. 这 3 张图整体在表达什么
|
||
|
||
这套图表达的是一套“统一移动入口、主后台统一编排、历史后台保留独立边界、供应商能力受控接入”的系统架构。
|
||
|
||
它的核心目标不是把所有历史系统都并进一个后台，而是在保留实际业务边界的前提下，把移动端访问链路重新组织成一个清晰、可治理、可演进的体系。
|
||
|
||
3 张图分别承担不同职责：
|
||
|
||
- `System Overview`
|
||
说明系统能力分别归谁拥有，重点是“谁负责什么”。
|
||
- `System Architecture`
|
||
说明系统按层分布后的结构关系，重点是“系统怎么连接、怎么治理”。
|
||
- `Key Flows and Context Governance`
|
||
说明关键业务链路在运行时如何流转，重点是“具体流程怎么走、异常和上下文怎么管”。
|
||
|
||
这 3 张图共同强调以下架构原则：
|
||
|
||
- `Mobile App -> App Backend` 是唯一主访问链路。
|
||
- `App Backend` 是 APP 的主后台和统一业务编排中心。
|
||
- `Mini Program Backend` 继续保持独立后台域，不直接并入主后台。
|
||
- `F6 Supplier Domain` 是供应商能力域，不被定义为 APP 主后台。
|
||
- `Mobile App -> F6` 只允许发生在嵌入式 `WebView` 场景。
|
||
- `App Backend -> F6 APIs` 必须经过 `F6 Integration Adapter`。
|
||
- 历史 Mini 直连链路只保留为兼容路径，不作为推荐默认方案。
|
||
|
||
---
|
||
|
||
## 2. 图例和颜色到底在表达什么
|
||
|
||
为了让读图的人在 3 页之间建立统一认知，这套图对颜色和线条语义做了固定约定。
|
||
|
||
### 2.1 颜色语义
|
||
|
||
- 蓝色区域和蓝色节点
|
||
表示 APP 本身和 `App Backend` 主域相关能力。
|
||
- 绿色区域和绿色节点
|
||
表示保留的 `Mini Program Backend` 历史业务域。
|
||
- 橙色区域和橙色节点
|
||
表示 `F6 Supplier Domain`、WebView 入口、供应商接入和集成适配层。
|
||
- 灰色区域和灰色说明
|
||
表示通用治理、跨域聚合、外部服务或非主业务实体说明。
|
||
- 红色点线
|
||
表示历史兼容链路，只是过渡保留，不是推荐设计。
|
||
|
||
### 2.2 连线语义
|
||
|
||
- 蓝色实线
|
||
表示主访问链路，也就是 APP 面向主后台的标准访问方式。
|
||
- 橙色虚线
|
||
表示 F6 相关的例外链路，包括嵌入式 WebView、换票和供应商访问路径。
|
||
- 灰色虚线
|
||
表示聚合访问、外部服务访问或跨域读取。
|
||
- 红色点线
|
||
表示历史兼容直连，不建议在新功能中继续复制。
|
||
|
||
这组语义在 3 页中都保持一致。第三页底部的 `Route Semantics` 也用线段样例再次标注这些规则，避免读图时只靠颜色文字理解链路含义。因此这套图并不是 3 张孤立页面，而是一套统一的架构表达。
|
||
|
||
---
|
||
|
||
## 3. 第一页：System Overview 详细说明
|
||
|
||
`System Overview` 是能力归属图。它的重点不是展示某个接口先调谁、后调谁，而是回答一个更基础的问题：
|
||
|
||
“整套系统里，不同能力到底归哪个域负责？”
|
||
|
||
这一页把系统划分成 4 个主域和 1 个底部治理带：
|
||
|
||
- `Mobile App`
|
||
- `App Backend`
|
||
- `Mini Program Backend Domain`
|
||
- `F6 Supplier Domain`
|
||
- `External Services + Governance Rules`
|
||
|
||
### 3.1 Mobile App：统一移动入口
|
||
|
||
左侧第一列是 `Mobile App`，代表用户真正使用的移动端容器。
|
||
|
||
这部分说明的是，APP 在架构中的职责主要是“承载、呈现、调用原生能力、维持当前会话”，而不是直接承担复杂跨系统编排。
|
||
|
||
它包含几个关键块：
|
||
|
||
- `Login / Agreement / App Shell`
|
||
表示 APP 是唯一统一入口，用户从这里进入整个系统。
|
||
- `WebView + JSBridge`
|
||
表示 APP 具备嵌入式 WebView 承载能力，但这里特别强调“只用于 F6 portal pages”，不是泛化的任意外部浏览器。
|
||
- `Native Capabilities`
|
||
表示扫码、相机、上传、蓝牙、通知等设备能力由 APP 容器掌控。
|
||
- `Store-Aware Session Holder`
|
||
表示 APP 本地会持有当前门店和角色上下文，但上下文本身的权威归属仍然在主后台。
|
||
|
||
换句话说，APP 主要负责：
|
||
|
||
- 提供统一入口。
|
||
- 承担页面容器。
|
||
- 调度设备能力。
|
||
- 保存当前会话状态。
|
||
|
||
但 APP 不负责：
|
||
|
||
- 多系统聚合编排。
|
||
- 供应商 API 直接调用。
|
||
- 业务权限主判断。
|
||
- 门店上下文主定义。
|
||
|
||
### 3.2 App Backend：主业务域和控制中心
|
||
|
||
中间第二列是 `App Backend`，这是整页最核心的部分。
|
||
|
||
这一列强调的是：APP 主后台不只是一个普通 API 服务，而是整个移动平台的控制面和编排中心。
|
||
|
||
它包含以下能力：
|
||
|
||
- `Auth and Token Center`
|
||
负责登录、令牌签发、刷新、退出和身份可信控制。
|
||
- `Store Context + Menu + Permission + Config`
|
||
负责当前门店、角色范围、菜单权限和配置下发。
|
||
- `Workbench Aggregation`
|
||
负责首页工作台、提醒、摘要和多个系统结果的统一返回。
|
||
- `Business Orchestration`
|
||
负责订单、采购、流程上下文和字段标准化。
|
||
- `WebView Ticket and Signing Entry`
|
||
负责 F6 WebView 场景的换票、上下文准备和 trace handoff。
|
||
|
||
这一列的含义非常明确：
|
||
|
||
- APP 所有主流程都应先到这里。
|
||
- 这里决定用户是谁、当前在哪个门店、可以看什么菜单、有什么权限。
|
||
- 这里负责把复杂的后端异构系统整合成移动端可用结果。
|
||
- 这里也是所有供应商接入和链路治理的统一出口。
|
||
|
||
如果没有这一层，移动端就会变成一个多后台直连客户端，导致：
|
||
|
||
- 门店和角色上下文不统一。
|
||
- 权限边界难以收口。
|
||
- 多系统异常无法统一处理。
|
||
- 供应商接入逻辑扩散到多个模块。
|
||
|
||
### 3.3 Mini Program Backend Domain：保留独立边界的历史系统域
|
||
|
||
第三列是 `Mini Program Backend Domain`。
|
||
|
||
这部分要表达的不是“历史系统不重要”，而是：
|
||
|
||
“这些系统仍然重要，但它们不是 APP 的统一主后台。”
|
||
|
||
图中列出了典型保留系统：
|
||
|
||
- `O2O`
|
||
- `Warranty`
|
||
- `Retail Store`
|
||
- `ROOS`
|
||
|
||
其中 `Retail Store` 对应“马上下单”体系中的门店注册、门店信息修改、店员管理等门店基础资料能力，不再使用容易被误解为交易订单的旧英文表述。
|
||
|
||
并通过说明卡强调：
|
||
|
||
- 它们仍然拥有历史业务数据和流程。
|
||
- 它们仍然可以是某些能力的 `Source of Truth`。
|
||
- 但面向 APP 的访问，原则上应通过 `App Backend` 聚合和标准化后暴露。
|
||
|
||
这部分架构表达非常重要，因为它避免了两个极端：
|
||
|
||
- 一个极端是误以为历史系统可以被立刻彻底替换。
|
||
- 另一个极端是继续把移动端做成多个小程序后台的直连入口。
|
||
|
||
正确做法是：
|
||
|
||
- 保留历史系统边界。
|
||
- 承认它们的业务归属。
|
||
- 但将移动端访问统一收束到主后台。
|
||
|
||
### 3.4 F6 Supplier Domain：供应商能力域
|
||
|
||
第四列是 `F6 Supplier Domain`。
|
||
|
||
这部分专门用来说明 F6 的定位：
|
||
|
||
- 它是供应商域。
|
||
- 它提供能力，但不是 APP 的主系统。
|
||
- 它既包含页面能力，也包含接口能力。
|
||
|
||
图中分成两类：
|
||
|
||
- `F6 WebView Pages`
|
||
- `F6 Capability APIs`
|
||
|
||
并给出代表性示例：
|
||
|
||
- WebView 例子：`Sales, scan, settlement, inbound`
|
||
- API 例子：`Procurement, activity, inventory sync`
|
||
|
||
这里的核心意思是：
|
||
|
||
- 页面可以在受控情况下嵌入到 APP WebView 中。
|
||
- API 不允许 APP 前端直接调用。
|
||
- 所有 API 级访问应通过 `App Backend` 内部适配层完成。
|
||
|
||
### 3.5 底部：External Services 和 Governance Rules
|
||
|
||
最底部是一条横向带，补充说明两件事：
|
||
|
||
- 系统还会依赖外部服务。
|
||
- 整套系统必须遵守统一治理规则。
|
||
|
||
外部服务示例包括：
|
||
|
||
- `SMS`
|
||
- `Marketing / CRM`
|
||
- `WeCom`
|
||
|
||
治理规则则明确写出 4 条核心边界：
|
||
|
||
- `App -> App Backend is primary`
|
||
- `App -> F6 only in Embedded WebView`
|
||
- `F6 APIs go through Adapter`
|
||
- `Mini direct access is legacy-only`
|
||
|
||
这 4 条规则可以理解为第一页的结论。整张图不只是介绍组件，而是在告诉所有参与方：
|
||
|
||
“系统边界和默认访问方式已经定了，新需求不要再随意绕开它。”
|
||
|
||
---
|
||
|
||
## 4. 第二页：System Architecture 详细说明
|
||
|
||
`System Architecture` 是分层架构图。它建立在第一页能力归属基础上，进一步解释系统按层组织后的技术结构。
|
||
|
||
如果第一页回答的是“谁负责什么”，那么第二页回答的是：
|
||
|
||
“这些能力在逻辑架构上如何分层组织，链路如何穿过这些层？”
|
||
|
||
这一页分成以下层次：
|
||
|
||
- `Client Tier`
|
||
- `Access & Security`
|
||
- `App Backend`
|
||
- `Integration Layer`
|
||
- `Mini Program Backend`
|
||
- `F6 Supplier Domain`
|
||
- `External Services`
|
||
- `Cross-Cutting`
|
||
|
||
### 4.1 Client Tier：客户端层
|
||
|
||
最上层是 `Client Tier`。
|
||
|
||
这里包含：
|
||
|
||
- `Store User Persona`
|
||
- `Mobile App`
|
||
- `Native Capabilities`
|
||
- `WebView + JSBridge`
|
||
|
||
这层说明的是：
|
||
|
||
- 用户并不是直接面对多个后端系统，而是面对一个统一 APP。
|
||
- 原生能力和 WebView 容器都属于客户端能力域。
|
||
- 客户端负责发起请求、展示页面、承载设备能力和 WebView 容器。
|
||
|
||
这里再次强调：`WebView + JSBridge` 是一种容器能力，不等于前端可以直接把供应商接口当成主链路使用。
|
||
|
||
### 4.2 Access & Security：接入与安全层
|
||
|
||
第二层是 `Access & Security`。
|
||
|
||
它包含：
|
||
|
||
- `API Gateway`
|
||
- `JWT / Auth`
|
||
- `WebView Allowlist`
|
||
|
||
这层表达的是系统接入不能裸奔，所有访问必须经过入口控制和安全校验。
|
||
|
||
#### API Gateway
|
||
|
||
`API Gateway` 代表统一 API 接入入口，负责：
|
||
|
||
- HTTPS / TLS 接入。
|
||
- 路由分发。
|
||
- 基础限流和治理。
|
||
- 将移动端和后端实现细节隔离。
|
||
|
||
#### JWT / Auth
|
||
|
||
`JWT / Auth` 代表统一身份凭证体系，负责：
|
||
|
||
- 令牌签发。
|
||
- 令牌刷新。
|
||
- 请求身份识别。
|
||
- 为后续权限和上下文建立可信基础。
|
||
|
||
#### WebView Allowlist
|
||
|
||
`WebView Allowlist` 是这一层里很关键的一个治理点。
|
||
|
||
它表达的是：
|
||
|
||
- 并不是任何外部 WebView 页面都可以被 APP 打开。
|
||
- 嵌入式 WebView 域名必须是受控、登记和允许的。
|
||
- 这既是安全规则，也是架构边界规则。
|
||
|
||
### 4.3 App Backend：主后台层
|
||
|
||
第三层是 `App Backend`，也是架构主域。
|
||
|
||
这里包含：
|
||
|
||
- `Identity & Store Center`
|
||
- `BFF Orchestration`
|
||
- `Workbench Aggregation`
|
||
- `WebView Ticket Center`
|
||
|
||
#### Identity & Store Center
|
||
|
||
这个模块负责：
|
||
|
||
- 用户身份。
|
||
- 门店主数据。
|
||
- 角色范围。
|
||
- 菜单权限。
|
||
|
||
它的意义是让系统具备统一上下文中心，否则每个后端域都按自己的方式解释用户和门店，会导致移动端体验严重割裂。
|
||
|
||
#### BFF Orchestration
|
||
|
||
这是面向移动端的统一 BFF 编排层，负责：
|
||
|
||
- 统一接口形态。
|
||
- 聚合和标准化多个后端返回。
|
||
- 减少前端直接理解多个后端协议的复杂度。
|
||
|
||
在架构里它是非常重要的一层，因为 APP 实际看到的“后端世界”，应该优先由它统一封装，而不是暴露历史系统差异。
|
||
|
||
#### Workbench Aggregation
|
||
|
||
这个模块更聚焦首页和工作台聚合能力，典型包括：
|
||
|
||
- 待办。
|
||
- 提醒。
|
||
- 门店经营摘要。
|
||
- 多来源业务 tile 数据。
|
||
|
||
它说明首页不是由单一系统直接返回，而是由主后台整合多个来源后下发。
|
||
|
||
#### WebView Ticket Center
|
||
|
||
这个模块专门解决 F6 WebView 场景下的入口控制问题，负责：
|
||
|
||
- 生成或换取 WebView 票据。
|
||
- 绑定当前用户和门店上下文。
|
||
- 传递 trace 信息。
|
||
- 为嵌入式 WebView 提供受控启动入口。
|
||
|
||
这意味着 APP 打开 F6 WebView 时，并不是裸跳 URL，而是先由主后台准备好上下文和票据条件。
|
||
|
||
### 4.4 Integration Layer：集成适配层
|
||
|
||
第四层是 `Integration Layer`。
|
||
|
||
这一层存在的意义，是把供应商接入复杂性控制在一个专门层里，而不是扩散进整个业务系统。
|
||
|
||
包含两个关键组件：
|
||
|
||
- `F6 Integration Adapter`
|
||
- `Timeout / Retry`
|
||
|
||
#### F6 Integration Adapter
|
||
|
||
它负责：
|
||
|
||
- 换票。
|
||
- 供应商访问上下文准备。
|
||
- 将主后台调用收口到统一适配出口。
|
||
|
||
本质上它是主后台访问 F6 的统一适配出口。
|
||
|
||
#### Timeout / Retry
|
||
|
||
这部分表达的是供应商链路治理能力，包括：
|
||
|
||
- 超时控制。
|
||
- 重试策略。
|
||
|
||
因为 F6 是外部能力域，不稳定性和响应波动风险都比内部模块更高，所以这里保留最关键的超时和重试治理。
|
||
|
||
### 4.5 Mini Program Backend：历史后台层
|
||
|
||
第五层是 `Mini Program Backend`。
|
||
|
||
这一层包含：
|
||
|
||
- `O2O Backend`
|
||
- `Warranty Backend`
|
||
- `Retail Store Backend`
|
||
- `ROOS Backend`
|
||
|
||
其中 `Retail Store Backend` 对应原“马上下单”相关的门店、人员、地址和资料维护能力，命名上按业务域表达为门店基础资料后台。
|
||
|
||
这层的架构含义不是“这些服务很次要”，而是：
|
||
|
||
- 它们继续承担原有业务责任。
|
||
- 它们可以是数据主来源。
|
||
- 但移动端调用它们时，优先通过主后台聚合。
|
||
|
||
这页里灰色虚线从 `BFF Orchestration` 向下扇出，就是在表达：
|
||
|
||
- 主后台聚合多个 Mini 域。
|
||
- 主后台对外统一返回。
|
||
- APP 不应把它们当多个主后台直接使用。
|
||
|
||
### 4.6 F6 Supplier Domain：供应商能力层
|
||
|
||
右侧是 `F6 Supplier Domain`。
|
||
|
||
这里分成两个主要能力：
|
||
|
||
- `F6 WebView Pages`
|
||
- `F6 Capability APIs`
|
||
|
||
它们分别对应两种不同访问模式：
|
||
|
||
#### F6 WebView Pages
|
||
|
||
用于页面嵌入场景，例如：
|
||
|
||
- 销售开单。
|
||
- 扫码。
|
||
- 结算。
|
||
- 入库。
|
||
|
||
访问特点是：
|
||
|
||
- 页面最终可能由移动端 WebView 直接打开。
|
||
- 但打开前需要经过主后台准备票据和上下文。
|
||
- 域名必须在 Allowlist 中。
|
||
|
||
#### F6 Capability APIs
|
||
|
||
用于系统间能力调用，例如：
|
||
|
||
- 采购。
|
||
- 促销。
|
||
- ERP 补充能力。
|
||
|
||
访问特点是：
|
||
|
||
- 前端不能直接调用。
|
||
- 只能从 `App Backend -> Integration Adapter -> F6 APIs` 发起。
|
||
|
||
### 4.7 External Services：外部服务层
|
||
|
||
底部右侧是 `External Services`，包括：
|
||
|
||
- `SMS`
|
||
- `Marketing / CRM`
|
||
- `WeCom`
|
||
|
||
这说明 APP 主后台除了对接历史内部域和供应商域外，也会调用一些外部平台服务。
|
||
|
||
这些服务通常承担：
|
||
|
||
- 短信验证码。
|
||
- 营销或客户关系数据。
|
||
- 企业协同消息。
|
||
|
||
它们本质上也是外部依赖，因此在架构里被单独表达，而不是混在主后台内部。
|
||
|
||
### 4.8 Cross-Cutting：横切关注点
|
||
|
||
右上方还有一组 `Cross-Cutting` 模块：
|
||
|
||
- `Observability`
|
||
- `Audit / Security`
|
||
- `Config Center`
|
||
|
||
这些不是某个独立业务流程，而是所有流程都必须共享的治理能力。
|
||
|
||
#### Observability
|
||
|
||
负责：
|
||
|
||
- Trace ID
|
||
- 日志
|
||
- 指标
|
||
|
||
确保跨域链路可追踪。
|
||
|
||
#### Audit / Security
|
||
|
||
负责：
|
||
|
||
- 敏感信息控制。
|
||
- 关键行为留痕。
|
||
- 审计证据保留。
|
||
|
||
#### Config Center
|
||
|
||
负责：
|
||
|
||
- 菜单配置。
|
||
- 开关配置。
|
||
- WebView 入口策略。
|
||
|
||
这部分说明 APP 平台不是硬编码系统，而是需要较强配置化能力支撑运营和演进。
|
||
|
||
### 4.9 第二页想强调的核心结论
|
||
|
||
第二页最终想让读图人形成以下认知：
|
||
|
||
- 客户端只有一个统一入口。
|
||
- 安全和接入必须前置。
|
||
- 主后台必须承担统一 BFF 和统一上下文职责。
|
||
- 供应商接入必须通过适配层治理。
|
||
- 历史 Mini 域继续存在，但面向 APP 的输出需要经由主后台整合。
|
||
- 所有跨域链路都要可观测、可审计、可配置、可降级。
|
||
|
||
---
|
||
|
||
## 5. 第三页：Key Flows and Context Governance 详细说明
|
||
|
||
第三页是运行时流程图。它不是在重新画系统结构，而是在解释：
|
||
|
||
“当业务真实运行起来时，这套架构的关键行为是怎么发生的？”
|
||
|
||
这一页选了 4 条最关键的流程：
|
||
|
||
- `Flow 1 Login and Store Context Bootstrap`
|
||
- `Flow 2 F6 WebView Launch and Session Rules`
|
||
- `Flow 3 Home Aggregation and Mini Compatibility`
|
||
- `Flow 4 Hybrid Procurement and Inbound Flow`
|
||
|
||
同时底部补充统一治理规则。
|
||
|
||
### 5.1 Flow 1：Login and Store Context Bootstrap
|
||
|
||
这条流程解释登录后的上下文建立过程。
|
||
|
||
流程步骤是：
|
||
|
||
1. `App Login`
|
||
2. `Token Issue`
|
||
3. `Store List + Default Store`
|
||
4. `Menu / Permission / Config Baseline`
|
||
5. `Context Established`
|
||
|
||
这个流程在架构上的真正含义不是“登录成功返回 token”这么简单，而是：
|
||
|
||
- 用户身份只是第一步。
|
||
- 系统真正可运行还需要建立当前门店上下文。
|
||
- 菜单、权限和配置要跟门店和角色一起确定。
|
||
- APP 登录后不是只有一个用户态，而是一个“用户 + 门店 + 角色 + 菜单 + 配置”的完整工作上下文。
|
||
|
||
所以这条流程强调的是：
|
||
|
||
- `Store Context` 是核心控制对象。
|
||
- 登录完成不代表业务上下文完成。
|
||
- APP 中很多行为都依赖这一步建立出的当前门店语义。
|
||
|
||
### 5.2 Flow 2：F6 WebView Launch and Session Rules
|
||
|
||
这条流程解释 F6 WebView 嵌入为什么是“例外链路但仍然受控”。
|
||
|
||
流程步骤是：
|
||
|
||
1. `App asks for WebView entry`
|
||
2. `Backend exchanges / prepares ticket`
|
||
3. `Embedded open in WebView`
|
||
|
||
并补充 3 条强规则：
|
||
|
||
- `Store switch invalidates WebView`
|
||
- `Expired ticket needs refresh`
|
||
- `Failure fallback shows safe message + trace ID`
|
||
|
||
这条流程表达的重点有 4 个：
|
||
|
||
#### 第一，WebView 入口必须由主后台签发
|
||
|
||
APP 不是拿到一个 URL 就直接打开，而是要先通过主后台获取受控入口。
|
||
|
||
#### 第二，WebView 会话受当前门店上下文约束
|
||
|
||
如果用户切换门店，当前 WebView 会话不能继续沿用旧上下文，否则会造成门店数据串用和权限风险。
|
||
|
||
#### 第三，票据是时效性的
|
||
|
||
过期票据需要刷新，而不是无限复用。
|
||
|
||
#### 第四，失败时必须可支持排障
|
||
|
||
如果 F6 打不开，不能只给用户一个空白页或技术错误，而是要给出安全提示并带 trace 信息，方便客服、研发和集成排查。
|
||
|
||
### 5.3 Flow 3：Home Aggregation and Mini Compatibility
|
||
|
||
这条流程解释首页工作台为什么一定是聚合页，而不是某个单体后端直接吐数据。
|
||
|
||
流程步骤是：
|
||
|
||
1. `Workbench request`
|
||
2. `Backend aggregates O2O / Warranty / ROOS / Config`
|
||
3. `Partial failure returns degradable tiles`
|
||
4. `Legacy Mini direct access is compatibility only`
|
||
|
||
这条流程的重点非常明确：
|
||
|
||
#### 第一，首页是聚合结果
|
||
|
||
首页的数据来源天然分散，不可能全部只来自一个系统。
|
||
|
||
#### 第二，主后台要负责标准化
|
||
|
||
不同 Mini 域返回结构、状态和错误处理方式可能不同，需要统一加工后再交给 APP。
|
||
|
||
#### 第三，降级方式必须是“局部降级”
|
||
|
||
如果其中一个来源失败，不应该让整个首页白屏，而应该：
|
||
|
||
- 哪个 tile 有问题就降级哪个 tile。
|
||
- 其他可用部分继续返回。
|
||
|
||
#### 第四，历史直连不是默认解法
|
||
|
||
即使某些 Mini 场景短期仍保留兼容直连，也应明确标记为历史兼容路径，而不是继续作为新功能访问方式。
|
||
|
||
### 5.4 Flow 4：Hybrid Procurement and Inbound Flow
|
||
|
||
这条流程解释采购和入库为什么是“混合模式”。
|
||
|
||
流程步骤是：
|
||
|
||
1. `Retail store context + permission + normalization`
|
||
2. `F6 owns procurement / promotion / ERP`
|
||
3. `Inbound execution uses WebView or API path`
|
||
4. `Historical data may still come from Mini aggregation`
|
||
|
||
这条流程在业务上很关键，因为它说明采购和入库类能力并不是纯内部能力，也不是纯供应商能力，而是一个混合场景。
|
||
|
||
它的架构含义是：
|
||
|
||
- 主后台负责上下文、权限和统一口径。
|
||
- F6 负责其擅长和实际拥有的供应商能力。
|
||
- 页面型操作可能通过 WebView 完成。
|
||
- 接口型能力通过适配层访问。
|
||
- 部分历史辅助数据可能仍来自 Mini 域聚合。
|
||
|
||
这也解释了为什么：
|
||
|
||
- 不能把 F6 当主后台。
|
||
- 也不能假装采购和入库完全脱离 F6。
|
||
- 更不能让前端自己到处直连多个系统完成业务。
|
||
|
||
正确解法是由主后台掌控主流程，由供应商承接其能力边界内的部分。
|
||
|
||
---
|
||
|
||
## 6. 底部治理规则和线段语义在告诉我们什么
|
||
|
||
第三页底部的 `Shared Governance Rules`、`Route Semantics` 和 `Review checks` 不是补充装饰，而是整套架构落地的检查清单和读图规则。
|
||
|
||
### 6.1 Shared Governance Rules
|
||
|
||
这里明确了 4 条总规则：
|
||
|
||
- `Store context is owned by App Backend`
|
||
- `F6 WebView is an embedded exception`
|
||
- `Mini systems remain independent`
|
||
- `Every degraded or supplier-facing failure returns a user-safe message and a trace ID`
|
||
|
||
它们分别约束：
|
||
|
||
- 上下文归属。
|
||
- 例外链路边界。
|
||
- 历史系统独立性。
|
||
- 失败处理方式。
|
||
|
||
### 6.2 Route Semantics
|
||
|
||
这里用线段样例说明第三页所有关键链路的读法：
|
||
|
||
- `Primary App route`
|
||
对应蓝色实线，表示 APP 到主后台的标准主链路。
|
||
- `F6 embedded / exception`
|
||
对应橙色虚线，表示 F6 WebView 嵌入、票据换取或供应商例外链路。
|
||
- `Aggregation / external`
|
||
对应灰色虚线，表示主后台向 Mini 域、外部服务或聚合来源发起的访问。
|
||
- `Legacy compatibility`
|
||
对应红色点线，表示历史兼容路径，只能作为过渡保留，不能作为新功能默认链路。
|
||
|
||
这部分和第二页的图例保持一致，目的是让评审人员在看流程图时能直接区分“主链路、例外链路、聚合链路、历史链路”，避免把 F6 WebView 或 Mini 直连误解成默认访问方式。
|
||
|
||
### 6.3 Review Checks
|
||
|
||
这里的检查项可以直接作为评审问题来问：
|
||
|
||
1. 门店切换是否会关闭当前供应商 WebView 会话。
|
||
2. 首页失败是否按 tile 降级而不是整页失败。
|
||
3. 采购和入库是否保持 F6-first 的供应商能力归属。
|
||
4. Mini 直连是否被严格控制为过渡链路。
|
||
|
||
如果某个新需求或技术方案违反了这里的检查项，通常意味着它已经偏离当前架构原则。
|
||
|
||
---
|
||
|
||
## 7. 为什么必须这样设计
|
||
|
||
这套架构不是为了“画得好看”，而是为了解决当前业务现实中的几个核心问题。
|
||
|
||
### 7.1 解决多入口和多后台混乱
|
||
|
||
历史上不同能力分散在多个小程序和后台里，APP 如果继续直接对接多个后端，移动端复杂度会越来越高。
|
||
|
||
统一 `App Backend` 作为主后台后，可以：
|
||
|
||
- 收敛前端访问入口。
|
||
- 统一账号和门店上下文。
|
||
- 统一权限和配置。
|
||
|
||
### 7.2 保留历史资产而不是强行推倒重来
|
||
|
||
Mini Program Backend 仍然保留业务边界，避免为了“统一”而做不现实的大拆大建。
|
||
|
||
这使系统具备：
|
||
|
||
- 现实可落地性。
|
||
- 渐进式演进能力。
|
||
- 更低迁移风险。
|
||
|
||
### 7.3 把 F6 当成供应商能力，而不是主系统
|
||
|
||
这是整个架构中最重要的认知之一。
|
||
|
||
因为 F6：
|
||
|
||
- 不是自有主后台。
|
||
- 协议和稳定性不完全可控。
|
||
- 同时提供页面和接口两类能力。
|
||
|
||
所以必须：
|
||
|
||
- 页面入口受控。
|
||
- API 接口后端统一适配。
|
||
- 供应商异常和主系统隔离。
|
||
|
||
### 7.4 支持真实业务运行中的上下文治理
|
||
|
||
系统不是“登录就结束”，而是多门店、多角色、多链路环境下持续运行。
|
||
|
||
因此必须把以下能力做成架构级规则：
|
||
|
||
- 当前门店上下文。
|
||
- WebView 会话绑定和失效控制。
|
||
- 跨域链路可追踪。
|
||
- 失败时可降级、可审计、可支持排障。
|
||
|
||
---
|
||
|
||
## 8. 读完这 3 页后应该形成的统一认知
|
||
|
||
如果要用一句话总结这 3 页图，它表达的是：
|
||
|
||
“Continental Retail APP 是一个以 `App Backend` 为统一主后台、以 `Mobile App` 为统一入口、以 `Mini Program Backend` 为保留独立历史域、以 `F6` 为受控供应商能力域的混合架构系统。”
|
||
|
||
更具体地说，所有参与方应形成以下共识：
|
||
|
||
- APP 不是多个后台的并列客户端，而是统一入口。
|
||
- `App Backend` 不是普通接口层，而是控制面和编排中心。
|
||
- Mini 后台继续存在，但面向 APP 时应优先通过主后台聚合。
|
||
- F6 是供应商域，页面和接口都要按受控方式接入。
|
||
- 门店上下文是系统运行的核心治理对象。
|
||
- 首页聚合必须支持局部降级。
|
||
- WebView 是例外链路，不是默认业务通路。
|
||
- 所有跨域链路都必须可治理、可观测、可审计。
|
||
|
||
---
|
||
|
||
## 9. 这份说明适合怎么使用
|
||
|
||
这份文档适合以下用途：
|
||
|
||
- 架构评审时作为讲解稿。
|
||
- 产品、研发、测试 onboarding 时作为系统认知材料。
|
||
- 需求讨论时用于确认是否违反既定架构原则。
|
||
- 接口联调前用于统一系统边界和责任分工。
|
||
|
||
如果后续需要，我还可以继续补两类配套文档：
|
||
|
||
- 一份“面向评审汇报”的精简版讲稿。
|
||
- 一份“按模块拆解”的实现说明，把图里的每个块映射到实际研发任务和接口边界。
|