NingG +

技术成长系列:状态机的通用设计和实现

  1. 讨论焦点:分析、设计状态机的极简思路和要点,不涵盖 BPM,也不涵盖 Activiti 类似的框架;
  2. 结果预期:一般场景下,能够快速、准确设计一个合适的状态机,平滑支撑业务\架构演进;
  3. 这篇分享,整理有 keynote

概要

几个朴素的问题:

  1. 状态机,是什么?
  2. 有什么价值?
  3. 具体业务场景中,如何设计一个合适的状态机?
  4. 怎么实现一个状态机?

实际上,作为架构师,面对一个具体场景,需要进行一系列的准备工作(前期的分析、设计)。

这些分析和设计工作,有几个重要产出:

  1. 业务子系统拆分(拆分预期)
  2. 服务化拆分边界(拆分预期)
  3. 领域模型
  4. 状态机

至于其他的分库分表、中间件引入等是业务发展到一定阶段的具体技术点,不是针对一个完整场景的架构设计,有缘分今后会细讲。

做一点分享,通过反复分析人月神话以及敏捷开发实践,时间的分配上,我的心理有个基本标准:设计、开发、测试,3+3+3

目标

关于状态机的设计和实现:

  1. 基本规则
  2. 可行步骤
  3. 最佳实践
  4. 讨论

面向对象:

  1. 技术团队
  2. 产品团队
  3. 业务、技术感兴趣的同学

简介:状态机

基本原则:

  1. 状态互斥
  2. 严格流转

关键点:

  1. 状态:
    1. 暂态
    2. 终态
  2. 触发方式:
    1. 时间触发
    2. 事件触发

状态机设计的可行步骤:

  1. 分析:业务场景抽象,收集状态变更的条件筛选
  2. 设计:状态流转
  3. 实现

Note:

实例

场景

实验平台的场景:

实验平台中,实验的状态流转。

目标:

  1. 怎么设计一个状态机,平滑的支持业务?
  2. 怎么实现?实现细节上,有没有问题?

分析

  1. 对象实体:实验
  2. 实体的状态变更条件
    1. 创建
    2. 生效:开始时间,实验自动生效
    3. 暂停:人为操作
    4. 恢复:人为操作
    5. 结束:结束实践,实验自动结束
    6. 上线:人为操作
    7. 删除:人为操作
  3. 实体,不同状态下的权限
    1. 是否可编辑
    2. 是否可删除
    3. etc.

设计

设计过程

实现

软件设计原则:

状态流转

使用上面方式,一般几百行 java 代码,就能实现一个通用的状态流转,很简单清晰。

实现的部分细节:

总结

基本原则:

  1. 状态互斥
  2. 严格流转

关键点:

  1. 状态:暂态、终态
  2. 触发方式:时间触发、事件触发

状态机设计的可行步骤:

  1. 分析:业务场景抽象,收集对象实体状态变更的条件筛选
    1. 对象
    2. 状态以及变更条件
    3. 不同状态下的操作权限
  2. 设计:状态流转
  3. 实现:软件设计原则,SRP
Top