有关状态机设计的专家建议

Question

背景

我们正在设计一种微服务来管理系统中的预订。因此，我们决定使用状态机抽象来解决此问题，即预订可以处于多种状态之一，并且可以通过某些操作/事件转变为另一种状态。

我和我的同事之间进行了非常健康的讨论，并且我对应该如何设计状态机有不同的看法。 我以REDUX为例，其中我们有不同的 ACTIONS （事件+有效载荷），并且根据 ACTION.TYPE ，我们将系统转换为另一个州。

这很简单，但是我的朋友介绍了诸如 ACTIONS 和 EVENTS 之类的令人困惑的因素：两件完全不同的事情（我认为在任何状态机中它们都应该相同） 而且他认为，事件会导致某些 ACTIONS 在状态机上执行，从而转换为其他 STATE 。他的观点是事件和动作是两个完全不同的方面，不应相同。它们有不同的观点和含义。

例如，某些 EVENT 可能是 CREATE_REQUEST ，但实际上寻找可用性并进行预订是由 CREATE_REQUEST导出的 ACTION 事件。

但是我完全不同意，我强烈要求 ACTION 应该类似于 [CREATE_REQUEST，{DATES，... OTHER_INFO}] ，并且机器应相应执行并转换为其他 STATE 。

那应该是正确的方法。

├── src
|  ├── ACTIONS
|  ├────── CREATE_REQUEST // return {TYPE: CREATE_REQUEST, {data}}
|  ├────── DECLINE_REQUEST //return {TYPE: DECLINE_REQUEST, {id}}
|  ├── STATES
|  ├────── DRAFT
|  ├────── PENDING
|  ├────── REQUESTED
|  ├────── COMPLETE

我正在等待一些专家的建议和意见，以便我们对做什么有一个清晰的认识。

Answer 1

动作表示用户与之交互的内容。该事件是您的应用程序如何处理所述交互。在大多数情况下，明智的做法是根据项目的规模实施仲裁层。一旦确信了应用程序体系结构的重要性，就应该实现处理用户操作的事件。您只是不想将所有业务逻辑都放在行动中。这样做是确保代码无法维护的一种可靠方法。