事件攔截

訊息基礎架構

如果訊息基礎架構已經開始運作，那麼你很幸運 - 其主要優點之一是它將訊息的生產者與消費者分開。

像 Wire Tap、Message Router、Content-Based Router 等模式可用於攔截和/或建立事件，這些事件可以由新系統或現有的舊有系統路由和處理以進行處理。訊息基礎架構通常允許使用訊息標頭來過濾訊息，讓某些訊息可供消費者使用。例如，JMS 實作使用訊息選擇器來允許訊息提供者過濾訊息。如此便可達成簡單的攔截和路由。

在上述圖中，舊有消費者需要將其生產者設定為包含訊息選擇器（以有效新增篩選器）

更複雜的路由可能需要檢查訊息主體 - 在這種情況下（基於內容的路由），訊息需要由路由元件使用，檢查訊息載荷，並根據訊息內容按需要將訊息重新排入新的目的地佇列。

同樣地，舊有消費者需要重新設定為從新的目的地使用

反向代理 - 基於 URL、查詢參數或表單資料的路由
反向代理可以是建立和/或攔截事件的另一種非常有效的方法 - 讓您可以將 http(s) 要求重新導向到不同的資源。與訊息基礎架構類似 - 反向代理通常能夠在簡單檢查主機和埠部分、路徑、查詢參數和標頭後路由要求。

例如，根據表單資料內容路由要求可能需要自訂實作，但可以提供很大的彈性。

API 閘道

API 閘道在服務的公開端點和其實作之間提供一層間接。在粗略的層級上，API 閘道讓我們有機會套用 Branch by Abstraction 模式，讓閘道可以將所有要求路由到我們選擇的實作。在更精細的粒度上，也可能根據要求或載荷內容按需要路由服務要求。

在網路應用程式中 - 漸進式增強

此處的想法是對舊式網頁應用程式進行小幅變更，進而將現代化工作的發布週期與舊式應用程式的後續變更脫鉤。為此，您可以將指令碼元素新增至範本（或範圍內的每個頁面）。該指令碼可以隨著時間推移進行開發（並獨立發布），並使用漸進式增強來攔截使用者動作並視需要變更行為。例如，您可以使用此方法附加或覆寫事件處理常式，以變更表單提交到的 URL。在新增漸進式增強之前

以及之後

我們曾成功使用此方法的一個範例是在網頁商店中替換舊式產品圖片解決方案。我們建置了一個新系統，使用戶能夠提交多張產品圖片，並讓專業使用者進行品質保證。我們能夠對舊式商店的全球範本進行簡單變更，以新增指令碼標籤，其 JavaScript 內容可以獨立發布。指令碼在商店中使用漸進式增強，以檢查新系統是否具有產品圖片，如果有，則為這些圖片建立輪播。顯示具有多個詳細圖片的高階輪播，可以提高售價。

資料庫層 - 觸發器

當變更已傳遞到舊式資料庫時，您可能會認為攔截事件為時已晚。話雖如此，可以使用「預提交」觸發器來攔截資料庫寫入事件並採取不同的動作。例如，可以將列插入到單獨的事件表中，以便由新元件讀取/處理 - 同時繼續進行寫入（或中止寫入）。請注意，如果您變更現有的寫入行為，應特別小心，因為您可能會破壞重要的隱含合約。