假设我有一个大型中间件基础设施，用于调解多个业务组件（客户应用程序、网络、支付等）之间的请求。中间件堆栈负责编排、路由、转换和其他东西（类似于 Gregor Hohpe 的企业集成模式一书）。
我的问题是：把一些业务逻辑放在中间件上是不是很好的设计？
假设我的应用 A 从中间件请求一些客户数据。但为了获取这些数据，我必须提供客户 ID和其他一些参数。这个参数的获取应该由请求的应用程序完成，还是中间件负责“促进”并提供一个接收客户 ID并在内部获取其他参数的接口？
我意识到这不是一个简单的问题（因为业务逻辑的定义），但我想知道这是一种通用方法还是一些指导方针。
除了路由、转换和编排之外，在加载具有功能需求的中间件时还应牢记性能。中间件应该占用整个端到端事务生命周期的一小部分。这只能通过专注于中间件核心功能而不是试图补充主机系统功能来实现。
编排、路由和转换。
您不会出于技术原因随机执行这些操作，或者只是为了好玩，您这样做是因为您有一些业务需求——因此涉及到业务逻辑。
对于完整的业务系统，您唯一缺少的就是计算和报告（让我们假设您已经有了安全性！）。
除了非常低级别的网络，操作系统和存储问题几乎所有构成计算机系统的东西都在那里，因为企业/政府/最终用户希望它在那里。
选择“业务逻辑”作为术语非常糟糕，并导致设计和架构的无休止扭曲。
大多数优秀的设计师/架构师所说的业务逻辑是计算和分析。
如果您使用“%s/Business Logic/Calculation/g”，则大多数架构法令都更有意义。
中间件应用程序应该这样做。系统 A 应该不知道其他参数的存在，当然也不知道如何获取它。