event-handling - 限界上下文内部和外部的 EventSourcing

Question

我正在尝试使用 dddd 实现一个事件源系统。目前，我正在努力了解我的事件如何以及在何处跨越限界上下文的边界。

假设有两个限界上下文:

1. 产品管理
2. 物流系统

产品管理拥有关于产品的所有知识。为了简化，它只是“名称”。物流系统也有产品，但不知道它们的元数据。对于他们来说，它主要只是一个带有 Id 的物理盒子。但是当有人扫描这个产品时，他们也想显示这个名字。因此，产品管理 BC 应通知物流 BC，产品已注册且名称已更改。所以我将以 ProductManagement 中的事件结束，这些事件是从 ProductAggregate 内部引发的:

ProductManagement.Events.ProductRegistered
ProductManagement.Events.ProductNameChanged

当我正确理解这些是我将保存到事件存储中的事件。这些也是将发布到消息总线中的事件。所以在后勤方面我会订阅这些事件。到目前为止一切顺利。

现在的问题是:我将如何在物流方面处理此事件？ Vaughn Vernon 在一次演讲中说，最好的做法是在应用层有一个事件处理程序，所以它基本上是一个应用程序服务。他还说，最好将其转化为一个或多个命令。我是否再次在物流方面保存所有收到的事件？我是否也保存命令？如果出现问题，我如何重现当前状态？或者我怎么知道，这不是接收限界上下文中处理的错误，而是错误事件。如果我的转换命令被拒绝，我该怎么办？

我知道在物流方面没有计算或聚合变化。但我认为这对我的问题并不重要。

Answer 1

这里有几件事。

首先，您不必导入有关名称更改的物流 BC。您可以在需要时从客户端的 PM BC 获取此信息。这通常由某种复合 UI 完成。 UI 组合可以在客户端或(Web)服务器上完成。您可能需要查看文章 The secret of better UI composition Mauro Servienti 对此进行了描述。

但一般来说，这通常是这样工作的:

域事件 -> 发布/订阅 -> 消息消费者 -> 命令 -> 域命令处理程序

所以，

1. 您从 PM BC 将领域事件发布到总线
2. Logistics 中有此事件的事件处理程序
3. 事件处理程序可能会做一些检查，并将 RegisterProduct 命令发送到同一个 BC
4. 该命令照常处理，并在物流中创建新的Product 聚合

它不仅在事件源系统中如此工作，而且在使用事件驱动架构的具有多个服务的任何系统中也是如此。