事件采购 - 事件存储答案

【问题标题】：Event Sourcing - Event Store事件采购 - 事件存储
【发布时间】：2020-12-19 17:39:06
【问题描述】：

我正在尝试了解 DDD / Event-sourcing / CQRS 等。

让我们考虑一个具有以下微服务的电子商务应用程序。

order-service
shipping-service
payment-service

你能澄清这些问题吗？

【问题讨论】：

【解决方案1】：

通常，（逻辑）服务将拥有修改一个或多个流的专有权限。

只要服务知道如何找到这些流，这些流是一起在一个持久存储中还是分布在多个存储中并不特别重要。

同样，每项服务都有自己的商店通常并不是那么重要。从功能上讲，重要的是不同的服务不会写入其管辖范围之外的流。只要您确信两个服务不会尝试使用相同的流标识符，就可以了。

请注意，如果您的服务将行写入 RDBMS 中的表中，您将使用这两个指南。表不必在同一个数据库中，只要服务知道哪个数据库包含哪些表。同样，两个不同的服务可以共享同一个数据库，只要它们不写入彼此的表即可。

当然，您可能希望隔离不同服务的存储，这可能不是功能性的原因。例如，如果一个服务想要升级到新版本的存储，而另一个需要落后，那么如果这些服务不共享数据库会方便很多。同样，通过隔离数据存储更容易满足某些类型的审计。

如果我使用 CQRS 进行订单服务，我的问题是 - 谁应该使用支付事件。订单服务的命令端还是读取端？

如果您的订购域动态需要来自付款的信息，那么订购的命令端将需要来自付款的信息的副本。

付款信息是数据的unlocked copy - 即使我们正在更新订单，付款信息的权威副本也可能会发生变化。

假设您不想将订购与付款的域动态紧密结合，订购所使用的付款信息副本通常是一份报告（也称为“读取模型”），而不是整个历史记录的副本.

【讨论】：

还是有点困惑。如果我使用 CQRS 进行订单服务，我的问题是 - 谁应该使用支付事件。订单服务的命令端还是读取端？
我不确定它是否是紧耦合。订单状态取决于付款是否被批准。所以它应该消耗这些事件。因此，如果订单服务写入模型正在使用这些事件。如果订单服务必须根据支付和运输批准等多个事件做出决定 - 它是否会查询自己的事件存储以最终使订单完成状态？整个事件溯源似乎没有任何意义。