Skip to content

Latest commit

 

History

History
54 lines (46 loc) · 2.23 KB

2024-11-27-一篇文章彻底搞明白既熟悉又陌生的状态机设计好业务系统的状态机.md

File metadata and controls

54 lines (46 loc) · 2.23 KB

一篇文章彻底搞明白既熟悉又陌生的状态机设计好业务系统的状态机

TL;DR

本文总结了状态机设计规范,强调业务含义、流程驱动和状态流水,确保状态机易于理解、扩展和排查问题。

Summary

  1. 状态机规范

    • 新增状态需满足业务含义、流程驱动或初始/结束状态。
    • 状态含义明确,避免歧义。
    • 用户前台状态机与系统实现状态机可独立设计。
    • 状态机需具备状态流水能力。
    • 状态间转移关系需收敛到状态机。
    • 代码中引用状态枚举值,不引用数值。
    • 引用状态转移常量。
    • 维护状态机转移图或登记文档。
  2. 何时增加状态

    • 具备业务含义。
    • 用于流程驱动,如中间状态、待XX状态。
    • 初始或结束状态。
    • 判断业务含义:产品经理和用户能否理解状态文案。
  3. 评估状态全面性

    • 梳理业务模型执行流程和状态。
    • 画出状态转移图。
    • 评估是否存在不满足规范的场景。
  4. 流程驱动状态

    • 当前状态可执行哪些流程。
    • 什么状态下能执行流程。
    • 流程执行后进入什么状态。
    • 状态机驱动流程,状态决定流程。
  5. 多业务模型状态机数据一致性

    • 明确数据一致性规范。
    • 理解强一致性。
    • 业务上追求最终一致性。
    • 保证流程执行幂等。
    • 实现系统可靠的重试。
    • 数据核对快速发现不一致。
  6. 状态机和状态流水

    • 状态流水记录状态转移,具备业务含义,方便排查问题。
    • 设计状态流水包含模型唯一键、转移前状态、转移后状态、转移时间。
    • 异步增加状态流水。
    • 状态流水表检查非法状态转移。
  7. 总结

    • 设计状态机非简单任务。
    • 保证状态机含义正确、易于扩展、容易理解。
    • 明确状态机规范,指导团队达成目标。