實作不同子系統之間的外觀或配接器層，這些子系統不會共用相同的語意。 此層會轉譯一個子系統對另一個子系統提出的要求。 使用此模式可確保應用程式的設計不受外部子系統的相依性所限制。 此模式首先由 Eric Evans 在網域驅動設計中描述。
內容和問題
大部分的應用程式都依賴其他系統來取得某些數據或功能。 例如，當舊版應用程式移轉至新式系統時，它可能仍然需要現有的舊版資源。 新功能必須能夠呼叫舊版系統。 這特別適用於漸進式移轉，其中較大型應用程式的不同功能會隨著時間移至新式系統。
這些舊版系統通常遭受質量問題，例如卷積的數據架構或過時的 API。 舊版系統中所使用的功能和技術可能會因更現代化的系統而有所不同。 若要與舊版系統互通，新應用程式可能需要支援過時的基礎結構、通訊協定、數據模型、API 或其他您不會放入新式應用程式的功能。
維護新系統與舊版系統之間的存取權，可以強制新系統遵守至少一些舊版系統的 API 或其他語意。 當這些舊版功能有質量問題時，支援它們「損毀」，否則可能是全新設計的新式應用程式。
開發小組無法控制的任何外部系統，而不只是舊版系統，也可能發生類似的問題。
解決方案
將反損毀層放在兩者之間，以隔離不同的子系統。 這一層會轉譯兩個系統之間的通訊，讓一個系統保持不變，而另一個系統可以避免損害其設計和技術方法。
上圖顯示具有兩個子系統的應用程式。 子系統 A 會透過反損毀層呼叫子系統 B。 子系統 A 與反損毀層之間的通訊一律會使用子系統 A 的數據模型和架構。從反損毀層呼叫子系統 B 符合子系統的數據模型或方法。 反損毀層包含兩個系統之間轉譯所需的所有邏輯。 層可以實作為應用程式內的元件或獨立服務。
問題和考慮
- 反損毀層可能會增加兩個系統之間呼叫的延遲。
- 反損毀層會新增必須管理和維護的額外服務。
- 請考慮您的反損毀層如何調整規模。
- 請考慮您是否需要一個以上的反損毀層。 您可能想要使用不同的技術或語言將功能分解成多個服務，或有其他原因可以分割反損毀層。
- 請考慮如何管理與其他應用程式或服務相關的反損毀層。 它如何整合到您的監視、發行和設定程式中？
- 請確定已維護交易和數據一致性，並可加以監視。
- 請考慮反損毀層是否需要處理不同子系統之間的所有通訊，或只是功能子集。
- 如果反損毀層是應用程式移轉策略的一部分，請考慮它是否為永久的，或在移轉所有舊版功能之後淘汰。
- 此模式會以上述不同的子系統來說明，但也可以套用至其他服務架構，例如在整合型架構中整合舊版程式代碼時。
使用此模式的時機
當下列情況時，請使用此模式：
- 移轉計劃於多個階段進行，但需要維護新舊系統之間的整合。
- 兩個或多個子系統有不同的語意，但仍需要通訊。
如果新系統與舊版系統之間沒有顯著的語意差異，則此模式可能不適合。
工作負載設計
架構設計人員應該評估如何在工作負載的設計中使用反損毀層模式，以解決 Azure 架構架構支柱中涵蓋的目標和原則。 例如：
| 要素 | 此模式如何支援支柱目標 |
|---|---|
| 營運卓越可透過標準化的流程和小組凝聚力，協助提供工作負載品質。 | 此模式可協助確保新元件設計不會受到舊版實作所影響，這些實作在與這些舊版系統整合時可能會有不同的數據模型或商務規則，並可降低新元件中的技術債務，同時仍支援現有的元件。 - OE：04 工具和程式 |
如同任何設計決策，請考慮對其他可能以此模式導入之目標的任何取捨。