事件拦截

消息基础设施

如果消息基础设施已经存在，那么您很幸运 - 它的主要优势之一是它将生产者与消费者的消息解耦。

像 线路监听、消息路由器、基于内容的路由器 等模式可用于拦截和/或创建可以由新系统或现有遗留系统处理的事件。消息基础设施通常允许使用消息头来过滤消息，使某些消息可供消费者使用。例如，JMS 实现使用消息选择器来允许消息提供者过滤消息。通过这种方式，可以实现简单的拦截和路由。

在上图中，遗留消费者需要将其生产者配置为包含消息选择器（以有效地添加过滤器）

更复杂的路由可能需要检查消息正文 - 在这种情况下（基于内容的路由），消息需要由路由组件使用，检查消息有效负载，并将消息根据消息内容重新排队到新的目标队列中。

同样，遗留消费者需要重新配置以从新的目标队列中使用消息

反向代理 - 基于 URL、查询参数或表单数据的路由
反向代理可能是创建和/或拦截事件的另一种非常有效的方法 - 允许您将 http(s) 请求重定向到不同的资源。与消息基础设施类似 - 反向代理通常能够在简单地检查主机和端口部分、路径、查询参数和标头后路由请求。

根据表单数据的内容路由请求可能需要自定义实现，但可以实现很大的灵活性。

API 网关

API 网关在服务的发布端点及其实现之间提供了一层间接层。在粗粒度级别，API 网关使我们有机会应用 按抽象分支 模式，允许网关将所有请求路由到我们选择的实现。在更细粒度的级别，它也可能能够根据请求或有效负载的内容路由服务请求。

在 Web 应用程序中 - 渐进增强

这里的想法是对遗留 Web 应用程序进行小的更改，这将使现代化工作的发布周期与对遗留应用程序的进一步更改分离。为此，您可以将脚本元素添加到模板（或范围内的每个页面）。该脚本可以随着时间的推移而开发（并独立发布），并使用渐进增强来拦截用户操作并根据需要更改行为。例如，您可以使用这种方法来附加或覆盖事件处理程序以更改表单提交的 URL。在添加渐进增强之前

以及之后

我们看到这种方法成功使用的一个例子是在替换 Web 店面中的遗留产品图片解决方案时。我们构建了一个新系统，使用户能够提交产品的多个图片，并使专业用户能够对它们进行质量保证。我们能够对遗留店面的全局模板进行简单的更改以添加一个脚本标签，该标签的 Javascript 内容可以独立发布。该脚本在店面内使用渐进增强来检查新系统是否具有产品的图片，如果有，则为这些图片创建一个轮播。显示具有多个详细图片的先进轮播使销售价格能够提高。

数据库层 - 触发器

到更改已进入遗留数据库时，您可以争辩说，事件拦截已经太迟了。也就是说，“预提交”触发器可用于拦截数据库写入事件并采取不同的操作。例如，可以将一行插入到单独的事件表中，以便由新组件读取/处理 - 同时像以前一样继续写入（或中止写入）。请注意，如果您更改了现有的写入行为，则应格外小心，因为您可能会破坏重要的隐式契约。