TL;DR
ドメインが独立して進化できるように結合を減らし、あるドメインの概念を別のドメインの概念に変換するコンポーネント。
なぜ必要か
Microsoft の Azure Architecture Center によると、多くのアプリケーションは他のシステムのデータや機能に頼っている。レガシーシステムには、入り組んだデータスキーマや古い API といった品質の問題があることが多い。新しいシステムがそれらの API や意味づけに合わせると、きれいに設計できたはずの新しいアプリケーションが損なわれる。自分たちで管理できない外部システム全般で、同じ問題が起きる。このパターンは、Eric Evans が『Domain-Driven Design』で初めて示した。
仕組み
意味づけの異なるサブシステムの間に腐敗防止層を置き、両者の通信を変換させる。サブシステム A と腐敗防止層の間は常に A のデータモデルで通信し、腐敗防止層からサブシステム B への呼び出しは B のデータモデルに合わせる。変換に必要なロジックはすべて腐敗防止層に入れる。腐敗防止層は、アプリケーションの中のコンポーネントとしても、独立したサービスとしても作れる。
注意点
ここでいう「層」は、レイヤードアーキテクチャの各レイヤのことではない。ユースケースを覆う薄い保護膜のようなものを指す。
腐敗防止層を置くと、2 つのシステムの間の呼び出しに遅延が加わり、管理するサービスも増える。新旧のシステムの意味づけに大きな違いがなければ、このパターンは向かない。腐敗防止層には変換のロジックだけを置き、業務ルールやオーケストレーションを入れない。