比如状态的嵌套（substate），状态的并行（parallel，fork，join）、子状态机等等。
开源状态机性能差
除此之外，还有一个我不能容忍的问题是，这些开源的状态机都是有状态的（Stateful）的，表面上来看，状态机理所当然是应该维持状态的。但是深入想一下，这种状态性并不是必须的，因为有状态，状态机的实例就不是线程安全的，而我们的应用服务器是分布式多线程的，所以在每一次状态机在接受请求的时候，都不得不重新build一个新的状态机实例。
以电商交易为例，用户下单后，我们调用状态机实例将状态改为“Order Placed”。当用户支付订单的时候，可能是另一个线程，也可能是另一台服务器，所以我们必须重新创建一个状态机实例。因为原来的instance不是线程安全的。
这种new instance per request的做法，耗电不说。倘若状态机的构建很复杂，QPS又很高的话，肯定会遇到性能问题。
鉴于复杂性和性能（公司电费）的考虑，我们决定自己实现一个状态机引擎，设计的目标很明确，有两个要求：
- 简洁的仅支持状态流转的状态机，不需要支持嵌套、并行等高级玩法。
- 状态机本身需要是Stateless（无状态）的，这样一个Singleton Instance就能服务所有的状态流转请求了。
状态机实现
状态机领域模型
鉴于我们的诉求是实现一个仅支持简单状态流转的状态机，该状态机的核心概念如下图所示，主要包括：
- State：状态
- Event：事件，状态由事件触发，引起变化
- Transition：流转，表示从一个状态到另一个状态
- External Transition：外部流转，两个不同状态之间的流转
- Internal Transition：内部流转，同一个状态之间的流转
- Condition：条件，表示是否允许到达某个状态
- Action：动作，到达某个状态之后，可以做什么
- StateMachine：状态机
整个状态机的核心语义模型（Semantic Model）也很简单，就是如下图所示：
Note：这里之所以叫Semantic Model，用的是《DSL》书里的术语，你也可以理解为是状态机的领域模型。Martin用Semantic这个词，是想说，外部的DSL script代表语法（Syntax），里面的model代表语义（Semantic），我觉得这个隐喻还是很恰当的。
OK，状态机语义模型的核心代码如下所示：
//StateMachinepublic class StateMachineImpl
