异步消息传递（特别是发布/订阅式消息传递）作为域服务架构是否可行，还是仅在以 SOA 为中心的环境中可行？

Question

我一直在研究异步消息传递，我喜欢它优雅地处理某些领域内的一些问题的方式以及它如何使领域概念更加明确。但对于一般的领域驱动开发（至少在服务/应用程序/控制器层）来说，它是一种可行的模式吗？或者设计开销是否应该限制在基于 SOA 的场景（例如远程服务和分布式处理）？

Answer 1

好问题:)。异步消息传递的主要问题是，当人们使用过程或面向对象语言时，以异步或基于事件的方式工作通常非常棘手和复杂，并且程序员难以阅读和理解。如果业务逻辑以某种同步方式构建，那么它通常会更简单 - 调用方法并立即获取结果等:)。

我的经验法则通常是尝试在业务逻辑的微观层面上使用更简单的同步编程模型；然后在宏观层面使用异步和SEDA。

例如，提交采购订单可能只是将一条消息写入消息队列；但是采购订单的处理可能需要 10 个不同的步骤，所有这些步骤在高性能分布式系统中都是异步和并行的，并且具有许多并行进程和线程并行处理各个步骤。因此，宏观层面的布线是基于 SEDA 类型的方法，但在微观层面，各个 10 个步骤的代码主要可以采用同步编程风格编写。

Answer 2

就像许多架构和设计问题一样，答案是“视情况而定”。

根据我的经验，异步消息传递的优势在于它为设计带来的松散耦合。耦合可以是：

• 时间 - 可以异步处理请求，有助于整体可扩展性。
• 空间 - 正如您所指出的，允许以比许多同步设计更稳健的方式进行分布式处理。
• 技术 - 消息和队列是弥合技术差异的一种方法。

请记住，消息和队列是一种抽象，可以有多种实现。您不一定需要使用符合 JMS 的事务性高性能消息传递框架。如果正确实现，关系数据库中的表可以充当队列，其中的行作为消息。我已经看到这两种方法都取得了很好的效果。

Answer 3

顺便说一句，我也同意@BradS

顺便提一句 这是一种从业务逻辑中隐藏中间件的方法 同时仍然获得松散耦合和 SEDA 的好处 - 同时能够在各种不同的中间件技术之间轻松切换 - 从内存 SEDA 到 JMS 到 AMQP 到 JavaSpaces 到数据库、文件或 FTP 等