为我的非HTTP业务逻辑实现中间件设计是一个好主意吗？

Question

我们现在大多数人都习惯于使用从node.js生态系统开始的最新实现的HTTP中间件。我们还有一些业务逻辑（在应用程序扩展的单独业务逻辑库中），可以分层。这更像是一个操作队列（代码中的服务），它们响应提供给整个组件的外部消息，FILO样式。

伪代码将读取如下内容：

inviteFriendsOperation = createFIFOQueue(message)
inviteFriendsOperation.add(PrepareFriendsList)
inviteFriendsOperation.add(RemoveFamily)
inviteFriendsOperation.add(SendMobilePush { delete successfully pushed friends from message.friendList })
inviteFriendsOperation.add(SendWebPush { delete successfully pushed friends from message.friendList })
inviteFriendsOperation.add(SendEmail { here, message.friendList only contains those who failed for mobile and web push})
updatedMessage = inviteFriendsOperation.run()

print updatedMessage.successfulMobilePushes
print updatedMessage.successfulWebPushes
print updatedMessage.successfulEmails
print updatedMessage.friendList

因此，我们将创建一个执行操作的对象队列，并更新发送到该队列的message。它以add的顺序开始运行，到达SendEmail，然后返回到以PrepareFriendsList结尾的第一个操作。最后，作为整个操作的结果，它返回更新后的message。

message的界面将得到广泛应用，因此可以将误解降到最低。

除了HTTP中间件之外，我还没有看到这种模式经常使用，并且当我进行研究时，我发现了系统架构模式而不是代码的结果。

这是一个好方法吗？你能指出一些例子/论文/文章吗？

Answer 1

“类似中间件” 模式在您的情况下可能很有用。 中间件一词非常广泛。大多数时候，您会发现它在分布式应用程序的上下文中使用。在Web应用程序的上下文中，Web框架使用该模式来管理响应和请求对象。

我不会更详细地描述什么是中间件，但是这里有一些其他有用的设计模式。这些模式不仅类似于中间件，还尝试解决类似的问题。通常，不只有一种模式可以解决用例。

• Chain of Responsibility
• Intercepting Filter Pattern

我已经看到，通常在代码级别，这些模式与中间件具有相似的功能。如果可以找到更多示例，也许最好检查一下。

我不确定您的用例和基础架构，但是通常会出现的一个问题是步骤之间的错误处理。