洋葱架构中的 Kafka 消费者答案

【问题标题】：Kafka Consumers in Onion Architecture洋葱架构中的 Kafka 消费者
【发布时间】：2020-04-30 13:30:17
【问题描述】：

我正在处理一个关注DDD 的项目，并拥有consumers 到Kafka Queue。我的问题是直截了当的，Onion Architecture 和Hexagonal Architecture 中的消费者住在哪里？它们是事件处理程序还是应该成为基础架构的一部分？

我正在使用Kafka Consumers 来监听其他聚合根的更改事件，并希望将数据存储在我当前的aggregate 中。基本上是将数据从一个微服务复制到另一个微服务。

【问题讨论】：

标签： java domain-driven-design

【解决方案1】：

（Kafka）消费者的目的与例如消费者的目的非常相似。一个 RESTful 端点——它们都使用来自外部世界的消息/请求，以便将它们转换为 Application 可以理解的东西。所以，从Hexagonal Architecture 的角度来看，（Kafka）消费者只是一个适配器。

还要查看 Chris Richardson 的 Microservices Patterns 第 148 页的绘图，其中 queue consumer（又名 handler）被放置为 em>适配器在Hexagonal Architecture的上下文中。

从Onion Architecture 的角度来看，可以确定（Kafka）消费者不是应用程序核心的一部分 - 这是因为（Kafka）消费者只是提供/提供应用程序核心一个改编外部消息/请求。此外，洋葱架构的author 并没有指出outside layer 中应该放置这种适配器的确切位置，但是，正如人们所看到的，该层是分段的，所以，我想要么选择一个段（我会使用 Infrastructure）或简单地创建/发明一个（例如，可能是 Handlers）。

从Clean Architecture的角度来看，因为（Kafka）消费者只是一个适配器，它不能成为应用程序核心的一部分由实体和用例组成，但是是包含接口适配器的层的一部分（检查the image）。

另请参阅Clean Architecture 中的接口适配器部分。

【讨论】：

我认为您提出了一个很好的案例，验证了我将其作为基础架构一部分的决定。 + 1
谢谢！另请注意，我的回答与“2”点相矛盾。从接受的答案:)
我认为不会，因为 OP 在他的回答中所做的是将 Kafka 消费者分为 2 个部分，队列接收器代码（这是 infrastructure 的一部分）和对消息进行操作的代码（他称之为Use Case）。这样做有意义的原因是遵循CQRS 模式，您有不同的查询处理程序，您的Application Cnotrollers 和Kafka Consumers 创建Query Object 的实例，然后我们可以重用相同的代码（@987654335 @) 用于控制器和消费者。
考虑到这个观点（卡夫卡消费者的划分）我同意你的看法。我被“处理程序”这个词误导了（来自 DDD）；但这只是命名约定。

【解决方案2】：

我的看法是：

您的聚合是核心
消息处理程序是用例，它使用依赖项（如存储库接口）和核心来执行业务用例。
有基础架构代码可以从队列中窥探消息并触发用例

使用这种方法，您可以对用例进行单元测试，而无需担心基础架构，并且可以替换整个消息队列技术。同样的方法也适用于处理 API 请求。在实践中，唯一的区别是使用 API 可以同步返回响应，而使用消息传递则不能。

作为一个实用说明，在 .NET 中，我使用一个名为 Mediatr 的库来实现和触发用例。在 java 中，我发现PipelinR 乍一看很相似。这种方法允许您以相同的方式为所有同步和异步使用实现所有用例。

【讨论】：

正是我的想法。谢谢