Domain driven design 活动来源-活动商店

我试图了解DDD/事件来源/CQR等

让我们考虑以下微服务的E-COMM应用程序。

order-service
shipping-service
payment-service

你能澄清这些问题吗

• 我们可以将域关联为一个大型应用程序，将有界上下文关联为一个单独的微服务，rt
• 每个有界上下文/微服务是否会维护自己的事件存储？（基本上一个域可以有多个事件sotre？）
• 如果每个域将有一个事件存储，那么谁拥有事件存储的所有权

通常，（逻辑）服务具有修改一个或多个流的独占权限

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

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

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

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

---

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

如果您的订购域动态需要来自支付的信息，则订购的命令端将需要来自支付的信息的副本

付款信息是数据的一部分-即使在我们更新订单时，付款中该信息的权威副本也可能发生变化

---

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

如此一来，您每篇文章就有一个问题，抱歉。投票结束，直到编辑成一个问题。这些都是相关的问题。不是真的。将ms映射到BC是一个问题。活动商店是第二个。es的所有权和第二季度有关，所以我会告诉你们。仍然有点困惑。如果我使用CQR进行订单服务，我的问题是-谁应该使用支付事件。命令端还是读取端的订单服务？我不确定它是否是紧密耦合。订单状态取决于是否批准付款。所以它应该消耗这些事件。因此，如果订单服务写入模型正在使用这些事件。如果订单服务必须根据多个事件（如付款和发货已批准）做出决策，它是否查询自己的事件存储以最终确定订单完成状态？整个事件的来源似乎没有任何意义。