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

解决方案

回答

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

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

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

回答

像许多架构和设计问题一样，答案是"取决于情况"。

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

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

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

回答

我也同意@BradS

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