问涉及多个微服务之间异步通信的用户界面和进程

EN

首先思考:使内隐显化。旅行者为你提供了一个获得商业价值的机会；在这一点上，你绝对的首要任务是抓住这个机会--其他一切都可以等待。因此，您缺少了一个ReservationRequested事件；在您域的无处不在的语言中选择合适的拼写。

从理论上看，这看起来不错，但我是让事情变得过于复杂了，还是这是实现脱钩的一种方式？

在我看来，你好像走对了路。您可能需要检查您的设计，看看库存(可用性)是否与产品(营销、定价等)是一个独立的关注点。

通过使用这种方法，我不能通知旅行者“预订完成”，因为在后台有一个很长的运行过程。

这是正确的--但是，您应该在ReservationRequested事件中有足够的信息来知道哪个长期运行的后台进程将与该预订相关联(例如:进程id是根据保留请求中存在的值的哈希计算的)。

我倾向于通过将旅行者重定向到飞行过程的视图来实现ACK请求；如果他们在您取得任何进展之前遵循该链接，那么您将使用ReservationRequested事件来构建“我们收到了您的请求，您可以期望从……收到我们的请求”。消息，但该端点可用于在工作完成时提供流程的更新表示。

你的方向和设计看上去不错，有几点评论：

如果您可以让UI或API执行消息分发(而不是请求服务这样做)，通过让每个业务组件完成它的工作并发布一个事件，这将减少耦合和更好的扩展机会。

您可以使用的另一种模式是Saga (状态机)，这样您就可以更好地编排业务流程，并通过监听所有事件来了解您何时完成任务。

您可以查看一个佐贺在此实施示例

讲得通?