问题描述
我有一个 Order 服务，它使用这个事件并记录作为交易一部分购买的所有东西。因此，在确认销售后不久，这些购买的信息最终是一致的。
这种架构的好处是销售服务对其有巨大的容量需求，因此使其尽可能轻量级是理想的选择。
问题是...当确认销售时，销售服务需要在为该客户进行任何进一步交易之前知道购买了什么。这是因为他们可以购买的物品数量等有限制，以及其他限制。它不能依赖订单服务随时提供此信息，因为处理订单时可能会出现积压。
我可以通过让销售服务在确认销售后立即记录所有这些信息来解决这个问题，但随后我在销售服务中引入了更多的逻辑和处理。除了编写事件之外，它现在还计算作为订单一部分购买的所有商品并将其全部推送到其数据库中。
是否有解决此类问题的模式？我是否实际上被迫让销售服务也了解如何处理和存储订单？
解决方法
如果订单服务依赖于来自销售服务的事件来做出决策，并且销售服务需要与订单服务做出的决策高度一致，这强烈表明它们实际上是同一个服务。如果它们碰巧分开部署，就会形成一个分布式单体（很可能是两全其美）。
,您的选择是构建一个使用单个数据库的单体应用程序，或者接受最终一致性并在出现问题时依靠补偿。
请注意，在任何非玩具应用程序中，您无论如何都必须支持补偿。例如，承诺给客户的最后一件物品在包装过程中损坏了。这将需要取消或延迟订单。这种情况的处理与销售服务处理没有关于物品可用性的最新信息没有太大区别。
在使用队列和独立服务时，处理所有这些边缘情况实际上是不可能的。当采用像 temporal.io 这样的集中式编排解决方案时，这成为一个易于处理的问题。
免责声明：我是 Temporal 开源项目的技术负责人。