人们常说Kafka很适合领域驱动设计。
那么为什么Kafka的博客文章大多谈论CQRS或类似的东西--建议分开输入和输出的主题呢？
看起来一个主题可能是关于一件事的。为什么服务要“谈论”同一件事，并由谁/什么在谈论的实现细节来展开呢？
保护服务不受有问题导致它们发送垃圾邮件主题的对等体的影响，这不是很大的开销吗？
我希望你的回答能给出赞成/反对意见--为什么人们会认为一件事。而不是对“正确”答案的看法。如果这更适合另一个SO，我希望你能给我指出正确的方向。
人们常说Kafka很适合领域驱动设计。
那么为什么Kafka的博客文章大多谈论CQRS或类似的东西--建议分开输入和输出的主题呢？
看起来一个主题可能是关于一件事的。为什么服务要“谈论”同一件事，并由谁/什么在谈论的实现细节来展开呢？
保护服务不受有问题导致它们发送垃圾邮件主题的对等体的影响，这不是很大的开销吗？
我希望你的回答能给出赞成/反对意见--为什么人们会认为一件事。而不是对“正确”答案的看法。如果这更适合另一个SO，我希望你能给我指出正确的方向。
1条答案
按热度按时间nuypyhwy1#
总结一下
CQRS是一种在服务（Bounded context）中使用的模式，它允许您以不同的方式实现命令端和查询端，这就是CQRS的全部内容。
事件源是一种可选模式，您经常看到它与CQRS一起使用，但它不是必需的。
我把Kafka看作是服务之间的中坚力量，看作是服务之间的真理记录，就像下面这幅图怎么样：
在本例中，您使用Kafka来传递不同服务中发生的事情的通知（事件驱动架构），但我不会尝试使用Kafka进行请求/响应通信，即使这是可能的。
当你的目标是请求/响应模式时，你通常想要一个同步的响应，就像用户向系统发送一个命令一样。但是一般来说，为了减少耦合，你不应该在服务之间发送命令，最好是发布事件并让其他服务对这些事件做出React。