在系统设计时，难免需要给状态进行命名，命名看上去简单，实际上影响很大。状态在和上下游系统对接，业务沟通，自身代码编写都有很大影响，一个清晰的命名规范是非常重要的，现在根据个人理解整如下
现在我们要为B状态命名
A --event1--》B(Doing TaskX, Become status) --event2--》C
现在给B的状态命名
这里有几种命名方式
-
根据完成某个动作的后的状态（以event1的角度触发命名）
例如: 订单：PLACED，PAYED， DELIVERED， RECEIVED
这种命名
适合：如果非逆向流程以外，有多个分支，这种方式比较适合，CD舱门已经合上的状态叫做ClOSED,因为可能播放，也可能快进，也可能弹出。并且 如果系统和业务关注该状态已经完成某个动作，这个时候ed方式就比较适合。
不适合：对于查询不是特别好理解。也就是查询等待支付的订单的条件是PLACED
-
DOING， 正在进行持续性动作，中文就是XX中，这个是以以Doing TaskX的角度触发命名
例如：洗衣机，WASHING，RINSING，DRYING
这种命名
-
适合：在这个状态在系统层面就表示正在进行某种持续性的动作，并且这个持续性的动作就是环节的核心目的，用ING就比较合适。因为这个持续性的动作是该步骤存在的核心目的，是会带来很多附加值的产出，所以该动作是业务人员关注的点，而不是带来的说简单流程状态转换。这种情况用DOING比较合适。
譬如收货完成要进行质检，质检后就表示质检完成，等待上架。这时这个状态可以是收货完成，也可以是质检中，或者等待质检结果。如果质检是个核心环节，很多工作都是围绕这个来展开的，这个状态定义为质检中就比较合适。
-
-
Adj : 表示正处于该形容词描述的状态中，中文也叫XX中
这种方式和DOING类似，只不过在是个形容词
例如：active, inactive,
-
WAIT_某某事件 （根据event2命名）
例如：WAIT_PAY,
- 适合：
- 这个在系统实际使用中非常多，他表示整个系统处于IDIE状态，等待外部的一个事件。这个事件可能是外部系统的，或者人机交互的。清晰的告诉外界，系统现在什么也没有在干，等待进一步的输入。
- 这种命名对于定义状态和事件的绑定非常容易理解，WAIT_PAY作为source的事件必然是PAYED_EVENT。因为系统大多数处理的问题都是获取要处理的实体。注意是要处理，这种命名规则对于捞取这些数据有天然的自然的并且稳定的判断依据，不管系统状态如何增加，要支付的肯定是WAIT_PAY这个是万年不变的。
- 不适合
- 这个事件是个一次性的瞬时事件，不能是个持续的动作。
- 除了逆向以外，有多个分支，这种方式就不适合。因为他无法确定一个稳定的event
- 适合：
