Events 如果没有人需要传输级别上的可靠消息传递，那么如何在业务级别上实现可靠的PubSub？

这个问题主要是出于好奇。我不久前读到这篇文章，并同意应尽可能在业务级别应用可靠的消息传递

现在，问题是，他以点对点的方式清楚地解释了他的方法。但是，我不知道如何在发布/订阅情况下在业务级别实现可靠的消息传递

我将尝试通过显示命令（点对点）和事件（发布/订阅）来演示两者的区别。请注意，这些示例是高度简化的

---

命令：转账（uniqueId、金额、sourceAccount、recipientAccount）

如果账户持有人发送此转账，他可以等待确认

moneytransfered

（假设此事件将在

transfer

命令中包含对

uniqueId

的引用）

如果账户持有人在给定的超时时间内没有收到

转账

，他可以再次发送相同的命令。（当然，假设命令处理器是幂等的）

因此，我看到了可靠的消息传递是如何以点对点的方式在业务级别工作的

---

现在，假设我们前面的命令成功并生成了一个

MoneyTransfer

事件。在系统的某个地方，我们有一个事件处理器（

MoneyTransferMailNotifier

），它处理

MoneyTransfered

事件，并向转账接收者发送电子邮件通知

此

MoneyTransferMailNotifier

订阅了

MoneyTransfered

事件。但请注意，发送

MoneyTransfered

事件的系统并不真正关心此事件的侦听器是谁或有多少。这里的关键是解耦。我提出了一个事件，不关心是否有零个或20个侦听器我不订阅这个活动

---

此时，如果基础设施没有提供可靠的消息传递（至少一次传递），我们如何防止

MoneyTransfer

事件的丢失？我确实希望收件人收到他的电子邮件通知。

我看不出任何真正的“业务级”解决方案将如何解决这一问题

（1）我能想到的解决方案之一是明确订阅“业务级别”的事件，从而绕过任何基础架构组件。但我们现在不是在业务中引入基础架构吗

（2）另一个“解决方案”是引入一个流程管理器，它可以执行以下操作：

PM接收

传输

命令

PM将

传输

命令转发给账户子系统

如果成功，则向通知子系统发送命令

sendmailnotification（收件人）

---

这似乎是DDD规定的解决方案，对吗？但这不会引入更多的耦合吗

你觉得怎么样

编辑2016-04-16 可能根本问题有点过于简单：如果您没有一个基础设施组件来确保至少或准确地交付一次，您如何确保（当您处于最多一次的基础设施中时）您发出的事件将被接收？

并非所有事件都需要交付，但有许多是关键的（例如发送确认电子邮件的示例）

如果在传输级别上没有人需要可靠的消息传递，那么如何在业务级别上实现可靠的

PubSub

原始文章没有说明“没有人需要传输级别上的可靠消息传递”，而是说明应该在业务级别强制执行消息排序，因为在某些情况下，如果这种排序是业务的一个重要特征

在任何情况下，

PubSub

都是在基础架构级别，你不能说你在业务级别实现了

PubSub

，这是没有意义的

但是，您如何才能确保在业务级别只交付一次呢？通过使用

Saga/Process manager

。他们的重要职责之一就是这样。您可以将其与幂等

聚合

相结合。此外，您还可以识别强调从

通用语言中排序的术语，如取消>事务阶段

，并将它们包括在域模型中（例如作为事件的属性）

如果您没有确保至少 或者一次交付，您如何确保（当您处于 您的事件最多只会发出一次 收到？ 如果您没有至少一次，那么您可以使用它启动钻孔过程的第一个事件

在您的情况下，由于电子邮件的发送是一个重要的业务方面，我会将其作为流程中的一个步骤

此MoneyTransferMailNotifier已订阅MoneyTransfered事件。但请注意，发送MoneyTransfered事件的系统并不真正关心此事件的侦听器是谁或有多少。这里的关键是解耦。我提出一个事件，不关心是否有零个或20个侦听器订阅此事件

我相信，你的困惑就在这里——只有发布-订阅中间件才能将事件交付到它们需要的地方

格雷格·杨在他关于这个问题的演讲中谈到了这一点

总结：pub/sub中间件是个障碍。基于pull的模型，消费者从持久事件存储中检索数据，为您提供了从存储中检索消息的可靠方法。因此，您从存储中提取数据，然后像以前一样使用业务级数据来识别以前的工作

为了