防腐層設計模式-常用的架構設計原則

在不共享相同語義的不同子系統之間實施外觀或擴充卡層。 此層轉換一個子系統向另一個子系統發出的請求。 使用此模式可確定應用程式的設計不受限于對外部子系統的依賴。 此模式最先由 Eric Evans 在 Domain-Driven Design（域驅動的設計）中描述。

上下文和問題

大多數應用程式依賴于其他系統的某些資料或功能。 例如，舊版應用程式遷移到新式系統時，可能仍需要現有的舊的資源。 新功能必須能夠調用舊系統。 逐漸遷移尤其如此，随着時間推移，較大型應用程式的不同功能遷移到新式系統中。

這些舊系統通常會出現品質問題，如複雜的資料架構或過時的 API。 舊系統使用的功能和技術可能與新式系統中的功能和技術有很大差異。 若要與舊系統進行互操作，新應用程式可能需要支援過時的基礎結構、協定、資料模型、API、或其他不會引入新式應用程式的功能。

保持新舊系統之間的通路可以強制新系統至少支援某些舊系統的 API 或其他語義。 這些舊的功能出現品質問題時，支援它們“損壞”可能會是完全設計的新式應用程式。

不僅僅是舊系統，不受開發團隊控制的任何外部系統都可能出現類似的問題。

解決方案

在不同的子系統之間放置防腐層以将其隔離。 此層轉換兩個系統之間的通信，在一個系統保持不變的情況下，使另一個系統可以避免破壞其設計和技術方法。

上圖顯示了采用兩個子系統的應用程式。 子系統 A 通過防腐層調用子系統 B。 子系統 A 與防腐層之間的通信始終使用子系統 A 的資料模型和體系結構。防腐層向子系統 B 發出的調用符合該子系統的資料模型或方法。 防腐層包含在兩個系統之間轉換所必需的所有邏輯。 該層可作為應用程式内的元件或作為獨立服務實作。

問題和注意事項

• 防腐層可能将延遲添加到兩個系統之間的調用。
• 防腐層将添加一項必須管理和維護的其他服務。
• 請考慮防腐層的縮放方式。
• 請考慮是否需要多個防腐層。 可能需要使用不同的技術或語言将功能分解為多個服務，或者可能因其他原因對防腐層進行分區。
• 請考慮如何管理與其他應用程式或服務相關的防腐層。 如何将其內建到監視、釋出和配置程序中？
• 確定維護并可以監視事務和資料一緻性。
• 請考慮防腐層是要處理不同子系統之間的所有通信，還是隻需處理部分功能。
• 如果防腐層是應用程式遷移政策的一部分，請考慮該層是永久性的，還是在遷移所有舊功能後即會停用。

何時使用此模式

在以下情況下使用此模式：

• 遷移計劃為發生在多個階段，但是新舊系統之間的內建需要維護。
• 兩個或更多個子系統具有不同的語義，但仍需要進行通信。

如果新舊系統之間沒有重要的語義差異，則此模式可能不适合。