3

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

4

3 回答 3

5

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

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

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

于 2008-09-16T16:01:12.723 回答
2

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

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

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

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

于 2008-09-16T16:11:47.970 回答
1

我也同意@BradS 顺便说一句

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

于 2008-09-16T18:06:44.980 回答