是否有必要为微服务使用消息总线和 DDD 架构

Question

我阅读了很多关于 .NET 微服务的文档 他们中的大多数人使用（消息总线，DDD架构，事件处理程序，命令，...） 而这些令人困惑，这些有必要吗？ 对于微服务来说，我只是将我的应用程序分解成许多小的 API，它们有自己的数据库，具有干净的架构或没有洋葱架构（消息总线、DDD 架构、事件处理程序、命令，...），这是否可行？

Answer 1

您的架构选择是否“适合”您的目的是一个见仁见智的问题。

您在微服务中经常看到事件驱动的消息平面架构的原因是，它是一种可靠、可扩展、管理良好的方式，允许微服务之间进行通信 而无需它们直接相互交互.

对于新的微服务架构师来说，这是一种非常常见的反模式，其中一个“微服务”通过 HTTP 或 gRPC 或其他一些协议直接联系其他微服务。出现这种情况必然会将服务耦合在一起，从而使更恰当地认为是 distributed monolith.

接受 smart endpoints and dumb pipes 的概念（在您的示例中 - 消息传递平面是一系列哑管道）是实现真正的服务分离和微服务旨在提供的弹性的正确方法。