难以理解事件源微服务事件接收/通信

Question

我已经意识到事件源、CQRS、DDD和微服务有一段时间了，现在我想尝试并开始实施一些东西并尝试一些东西。

我一直在研究CQRS的技术方面，我理解其中的DDD概念。写入端如何处理来自UI的命令并发布其中的事件，以及读取端如何处理事件并在其上创建投影。

我遇到的困难是沟通

所以我想重点关注eventstore（这一个：https://eventstore.com/不那么模棱两可）。这就是我想要使用的，因为我知道它是事件源的完美选择，存储事件的简单性质意味着我也可以将其用于消息总线。

所以我的问题分为两个问题：

>

在微服务之间，我的日子更难过了...所以当看CQRS教程/讲座等时...他们似乎总是在谈论一个从用户界面/应用编程接口接收命令的孤立服务的例子。这很好。我知道编写端将附加一个应用编程接口，这样用户就可以与之交互来执行命令。例如，创建一个客户。但是...假设我有两个微服务，例如一个订单微服务和一个运输微服务，运输微服务如何从订单微服务中获取发布的事件。具体来说，这些客户事件如何转换为运输服务的命令。

让我们举一个简单的例子：-从订单的API创建的命令来下订单。-OrderPlacedEvent发布到事件存储。航运服务如何倾听并对此作出反应？它需要DispatchOrder并创建OrderDispatchedEvent。

那么，发货微服务的写入端是否需要轮询，或者也需要对订单流进行追赶订阅？如果是这样，如何使用DDD方法将事件转换为命令？

Answer 1

我遇到的困难是沟通

困难不是你的错——当谈到讨论管道时，DDD文献真的很弱。

Greg Young在Polygot Data演讲的后半部分讨论了订阅的一些问题。

Eventide项目的文档很好地解释了管道如何将事物装配在一起的原理。

在微服务之间，我过得更艰难...

基本思想：您的消息存储基本上是一个数据库；当您的微服务主机唤醒时，它会在某个检查点后查询消息存储，然后将它们提供给您的域逻辑（根据需要更新其自己的检查点本地副本）。

因此，主机从存储中提取一个包含事件的文档，并将该文档转换为处理（事件）命令流，最终传递给域组件。

换句话说，您构建了一个主机，该主机轮询数据库以获取信息，解析响应，然后将解析的数据传递给域模型，并编写自己的检查点。

Answer 2

类似于追赶订阅的东西可以用于订阅流，以接收写入流的任何事件

是的，使用追赶订阅是正确的做法。您还需要将订阅的流位置保持在某个位置。

在这里，您可以找到一些有效的示例代码。我不会发布整个片段，因为它太长了。

投影服务启动流程为：

• 加载检查点（第一次是流启动）
• 从该检查点订阅流

然后，运行时流将为：

• 然后订阅将在接收到事件时调用您提供的函数。有一些管道要做，比如如果您订阅了$all，您需要过滤掉系统事件（在下一个版本的事件商店中会更容易）
• 投射事件
• 存储新的检查点

如果将投影设为幂等，则可以不时存储检查点并保存一些IO。

运输微服务如何从订单微服务中获取发布的事件

当你构建一个全新的系统，并且你有一个小团队在处理所有组件时，你可以制作一个快捷方式，从另一个服务订阅域事件，就像你对投影所做的那样。在集成上下文中（在盒子之间），排序应该不重要，所以你可以使用持久订阅，这样你就不需要考虑检查点了。事件存储会为你做这件事。

请注意，它在发起服务的域事件模式上引入了紧密耦合。您的环境将具有合作关系，或者下游服务将是一个墨守成规的人。

当您继续使用系统时，您可能会决定正确解耦这些上下文。因此，您为发布事件供其他人使用的服务引入了一个稳定的事件API。您用于集成的同一订阅现在可以负责将域（内部）事件转换为集成（外部）事件。然后，消费上下文将使用稳定的API，上游服务的域模型将可以自由地迭代其域模型，只要他们保持转换是最新的。

下游上下文不需要使用事件存储，也可以使用消息代理。集成事件通常不需要持久化，因为它们是瞬态的。

我们正在举办一系列关于活动商店活动来源的网络研讨会，请访问我们的网站，按需访问以前的网络研讨会，您可能会发现有兴趣参加未来的网络研讨会。