这是否需要为微服务使用消息总线和 DDD 架构 [关闭]

Question

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

Answer 1

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

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

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

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