我正在使用六边形架构开发 Spring Boot 应用程序。该应用程序使用两个 Spring 状态机：一个用于请求进程，另一个用于接收进程。我的主要挑战是将这些状态机有效地集成到六边形架构中，特别是考虑到以下要求：
问题：
1。六边形架构中的业务逻辑实现：
在六边形架构中，哪里是实现状态转换逻辑的最佳位置，特别是考虑到在某些状态下发送/等待消息以及进行 REST 调用的需要？
2。状态机与服务层交互：
在这种情况下，我应该如何构建服务层和状态机之间的交互？我正在寻找适合六边形架构范例并确保可维护性的最佳实践。 状态相关的 REST 调用的配置：
您能否提供在 Spring Boot 中配置状态机（其中状态涉及进行 REST 调用）的示例或最佳实践？
3.处理消息回复：
如何有效管理状态机发送消息并需要等待响应才能进入下一个状态的场景？
4。对于状态转换，使用操作、侦听器或服务哪个更好？
任何指导、示例或最佳实践都会非常有帮助。感谢您的时间和帮助！
我的尝试和我的期望：
到目前为止，我已经按照六边形架构原则建立了应用程序的基本结构，将核心逻辑与外部依赖分开。我还实现了两个状态机的配置
期望：
对于消息传递逻辑，我希望状态机能够处理发送消息、暂停消息流，然后在收到相应响应后恢复或转换到新状态，类似于类似 TCP 的通信模型。
为了在各州做出决策，需要对其他组件进行 REST 调用。
1, 2：尚不清楚您如何使用状态机或为什么使用它们。但是，如果您将它们用作可以访问所有不同层（您提到的业务逻辑、消息+休息调用等）的协调器，那么这显然违反了架构。如果没有，那么应该直接放在哪一层。
2、3：我没有看到挣扎。如果您不执行异步调用，则在收到响应之前执行不会继续。有什么我没有看到的问题吗？
4：对于状态转换，我只看到要使用的操作。侦听器还可以用于其他一些操作，例如侦听错误