119 lines
6.1 KiB
Markdown
119 lines
6.1 KiB
Markdown
|
# 服务-状态映射分析报告
|
|||
|
|
|
|||
|
|
## 1. 状态机覆盖分析
|
|||
|
|
|
|||
|
|
### 已定义的状态机（11种）
|
|||
|
|
1. **Merchant（商户）状态**：pending → active → inactive → suspended
|
|||
|
|
2. **User（用户）状态**：pending → active → inactive → locked
|
|||
|
|
3. **Store（店铺）状态**：pending → active → inactive → suspended
|
|||
|
|
4. **Feature（功能）状态**：inactive → pending_payment → active → expired → suspended
|
|||
|
|
5. **Order（订单）状态**：pending → paid → split → processing → shipped → completed → refunded → cancelled
|
|||
|
|
6. **Cross-Border E-Commerce（跨境电商）状态**：PENDING → PROCESSING → CLEARANCE → SHIPPING → DELIVERED
|
|||
|
|
7. **SubOrder（子订单）状态**：pending → processing → shipped → completed → refunded → cancelled
|
|||
|
|
8. **Product（商品）状态**：draft → pending_approval → active → inactive → discontinued
|
|||
|
|
9. **Inventory（库存）状态**：normal → low → out_of_stock → overstock
|
|||
|
|
10. **Payment（支付）状态**：created → processing → paid → failed → refunded
|
|||
|
|
11. **Bill（账单）状态**：pending → confirmed → settled → disputed
|
|||
|
|
12. **Settlement（结算）状态**：pending → processing → completed → failed
|
|||
|
|
13. **Task（任务）状态**：pending → running → success → failed → cancelled
|
|||
|
|
|
|||
|
|
### 业务流程状态需求
|
|||
|
|
|
|||
|
|
#### 1. 数据采集与清洗闭环
|
|||
|
|
- 状态需求：RAW_DATA → CLEANED → ANALYZED → READY_FOR_LISTING
|
|||
|
|
- 覆盖情况：未覆盖
|
|||
|
|
- 问题：缺少数据采集与清洗的状态定义
|
|||
|
|
|
|||
|
|
#### 2. 商品刊登闭环
|
|||
|
|
- 状态需求：READY_FOR_LISTING → LISTING_IN_PROGRESS → LISTED → MONITORING → NEED_UPDATE → UPDATED
|
|||
|
|
- 覆盖情况：部分覆盖（Product状态机）
|
|||
|
|
- 问题：缺少LISTING_IN_PROGRESS、MONITORING、NEED_UPDATE状态
|
|||
|
|
|
|||
|
|
#### 3. 素材管理闭环
|
|||
|
|
- 状态需求：UPLOADED → PROCESSING → PENDING_REVIEW → APPROVED → IN_USE → ARCHIVED/REJECTED
|
|||
|
|
- 覆盖情况：未覆盖
|
|||
|
|
- 问题：缺少素材管理的状态定义
|
|||
|
|
|
|||
|
|
#### 4. 订单履约闭环
|
|||
|
|
- 状态需求：PULLED → PENDING_REVIEW → CONFIRMED → ALLOCATED → READY_TO_SHIP → SHIPPED → DELIVERED → CLOSED
|
|||
|
|
- 覆盖情况：部分覆盖（Order状态机）
|
|||
|
|
- 问题：缺少PULLED、PENDING_REVIEW、ALLOCATED、READY_TO_SHIP、CLOSED状态
|
|||
|
|
|
|||
|
|
#### 5. 售后逆向闭环
|
|||
|
|
- 状态需求：REQUESTED → PROCESSING → APPROVED → REFUNDED → COMPLETED
|
|||
|
|
- 覆盖情况：未覆盖
|
|||
|
|
- 问题：缺少售后处理的状态定义
|
|||
|
|
|
|||
|
|
#### 6. 报表与分析闭环
|
|||
|
|
- 状态需求：RAW_DATA → PROCESSED → GENERATED → DISTRIBUTED → FEEDBACK_APPLIED
|
|||
|
|
- 覆盖情况：未覆盖
|
|||
|
|
- 问题：缺少报表处理的状态定义
|
|||
|
|
|
|||
|
|
## 2. 状态流转一致性分析
|
|||
|
|
|
|||
|
|
### 状态变更原则
|
|||
|
|
- ✅ 所有状态变更必须通过Service
|
|||
|
|
- ✅ 禁止前端直接控制状态
|
|||
|
|
- ✅ 状态变更必须记录操作日志
|
|||
|
|
- ✅ 状态变更必须遵循预定义的流转路径
|
|||
|
|
- ✅ 状态变更可能触发相关业务逻辑
|
|||
|
|
|
|||
|
|
### 状态触发条件
|
|||
|
|
- ✅ 商户状态：审核结果、逾期未付费、违规行为
|
|||
|
|
- ✅ 用户状态：登录异常、权限变更、账号管理
|
|||
|
|
- ✅ 店铺状态：平台审核、违规行为、商户操作
|
|||
|
|
- ✅ 功能状态：支付结果、订阅到期、手动操作
|
|||
|
|
- ✅ 订单状态：支付结果、商户操作、物流状态
|
|||
|
|
- ✅ 商品状态：审核结果、库存状态、商户操作
|
|||
|
|
- ✅ 库存状态：库存数量变化、库存同步
|
|||
|
|
- ✅ 支付状态：支付渠道反馈、人工处理
|
|||
|
|
- ✅ 账单状态：系统确认、支付结果、人工处理
|
|||
|
|
- ✅ 结算状态：系统处理、支付结果、人工处理
|
|||
|
|
- ✅ 任务状态：任务触发、执行结果、人工取消
|
|||
|
|
|
|||
|
|
## 3. 服务-状态映射分析
|
|||
|
|
|
|||
|
|
### 核心服务的状态使用
|
|||
|
|
|
|||
|
|
| 服务流程 | 使用的状态机 | 状态流转是否完整 | 问题 |
|
|||
|
|
|---------|------------|----------------|------|
|
|||
|
|
| 功能开通闭环 | Feature状态 | 完整 | - |
|
|||
|
|
| 跨境电商闭环 | Cross-Border E-Commerce状态 | 完整 | - |
|
|||
|
|
| 多商户订单闭环 | Order状态 | 部分完整 | 缺少订单拆分状态 |
|
|||
|
|
| 订单履约闭环 | Order状态 | 部分完整 | 缺少履约中间状态 |
|
|||
|
|
| 结算闭环 | Settlement状态 | 完整 | - |
|
|||
|
|
| 权限校验闭环 | User状态 | 完整 | - |
|
|||
|
|
| 商户管理闭环 | Merchant状态 | 完整 | - |
|
|||
|
|
| 店铺管理闭环 | Store状态 | 完整 | - |
|
|||
|
|
| 自动选品闭环 | Task状态 | 完整 | - |
|
|||
|
|
| 自动上架闭环 | Task状态 | 完整 | - |
|
|||
|
|
| AI决策日志闭环 | Task状态 | 完整 | - |
|
|||
|
|
| 多租户数据隔离闭环 | - | 未覆盖 | 缺少租户状态 |
|
|||
|
|
|
|||
|
|
## 4. 状态管理问题
|
|||
|
|
|
|||
|
|
1. **状态定义不完整**：大量业务流程缺少对应的状态定义
|
|||
|
|
2. **状态流转不明确**：部分业务流程的状态流转路径未明确定义
|
|||
|
|
3. **状态触发条件缺失**：部分状态变更的触发条件未明确
|
|||
|
|
4. **状态与服务分离**：部分服务操作没有明确的状态更新逻辑
|
|||
|
|
|
|||
|
|
## 5. 改进建议
|
|||
|
|
|
|||
|
|
### 短期改进（1-2个月）
|
|||
|
|
1. **补全核心状态机**：优先实现数据采集、素材管理、售后处理等核心业务流程的状态定义
|
|||
|
|
2. **明确状态流转**：为每个业务流程定义完整的状态流转路径
|
|||
|
|
3. **关联状态与服务**：确保每个服务操作都有明确的状态更新逻辑
|
|||
|
|
|
|||
|
|
### 中期改进（3-6个月）
|
|||
|
|
1. **状态机可视化**：建立状态机可视化工具，便于理解和管理状态流转
|
|||
|
|
2. **状态监控**：实现状态变更监控，及时发现和解决状态异常
|
|||
|
|
3. **状态审计**：建立状态变更审计机制，确保状态变更的可追溯性
|
|||
|
|
|
|||
|
|
### 长期改进（6个月以上）
|
|||
|
|
1. **状态驱动设计**：采用状态驱动的设计方法，将状态作为业务逻辑的核心
|
|||
|
|
2. **状态机优化**：持续优化状态机设计，提高系统的可维护性和可扩展性
|
|||
|
|
3. **状态预测**：利用AI技术预测状态变更，提前做好业务准备
|
|||
|
|
|
|||
|
|
## 6. 结论
|
|||
|
|
|
|||
|
|
当前系统已经定义了13种核心实体的状态机，覆盖了部分业务流程的状态需求，但仍有大量业务流程缺少对应的状态定义。建议按照优先级逐步补全缺失的状态定义，明确状态流转路径，关联状态与服务操作，确保业务流程的状态管理完整和一致。
|