同じセマンティクスを共有しない異なるサブシステム間にファサードまたはアダプターレイヤーを実装します。 この層は、あるサブシステムが行う要求を他方のサブシステムに変換します。 外部サブシステムへの依存関係によってアプリケーションの設計が制限されないようにするには、このパターンを使用します。 Eric Evans は、「 Domain-Driven 設計: ソフトウェアの中心における複雑さに取り組む」でこのパターンを最初に説明しました。
コンテキストと問題
ほとんどのアプリケーションは、一部のデータや機能のために他のシステムに依存しています。 たとえば、レガシ アプリケーションを最新のシステムに移行する場合、アプリケーションは既存のレガシ リソースを引き続き使用する可能性があります。 新機能は、レガシ システムを呼び出すことができる必要があります。 この機能は、大規模なアプリケーションのさまざまな機能を時間の経過と同時に最新のシステムに移行する段階的な移行に特に重要です。
多くの場合、これらのレガシ システムには、畳み込みデータ スキーマや古い API などの品質の問題があります。 レガシ システムで使用される機能とテクノロジは、より最新のシステムとは大きく異なる場合があります。 レガシ システムと相互運用するには、新しいアプリケーションで古いインフラストラクチャ、プロトコル、データ モデル、API、または最新のアプリケーションに配置しないその他の機能をサポートすることが必要になる場合があります。
新しいシステムとレガシ システムの間でアクセスを維持する場合、新しいシステムは、少なくとも一部のレガシ システムの API またはその他のセマンティクスに準拠するように強制します。 これらのレガシ機能に品質の問題がある場合、このサポートは、それ以外の場合はクリーンに設計された最新のアプリケーションである可能性のあるものを破損させます。
開発チームが制御していない外部システムでも、同様の問題が発生する可能性があります。
ソリューション
破損対策レイヤーを配置して、異なるサブシステムを分離します。 このレイヤーは、2 つのシステム間の通信を変換します。 このアプローチを使用すると、一方のシステムを変更せずに、他のシステムの設計と技術的アプローチを損なうことなく維持できます。
このアーキテクチャのVisio ファイルをダウンロードしてください。
この図は、2 つのサブシステムを持つアプリケーションを示しています。 サブシステム A は、破損防止レイヤーを介してサブシステム B を呼び出します。 サブシステム A と破損対策レイヤー間の通信では、常にサブシステム A のデータ モデルとアーキテクチャが使用されます。破損防止レイヤーからサブシステム B への呼び出しは、そのサブシステムのデータ モデルまたはメソッドに準拠します。 破損防止レイヤーには、2 つのシステム間で変換するために必要なすべてのロジックが含まれています。 レイヤーは、アプリケーション内のコンポーネントとして、または独立したサービスとして実装できます。
問題と考慮事項
このパターンを実装する方法を決定するときは、次の点を考慮してください。
破損対策レイヤーは、2 つのシステム間の呼び出しに待機時間を追加します。
破損対策レイヤーでは、管理と保守が必要な追加のサービスが追加されます。
破損対策レイヤーをスケーリングする方法を検討します。
複数の破損対策レイヤーが必要かどうかを検討します。 たとえば、さまざまなテクノロジや言語を使用する複数のサービスに機能を分解できます。
他のアプリケーションまたはサービスに関連して破損対策レイヤーを管理する方法と、それを監視、リリース、構成のプロセスに統合する方法を検討してください。
トランザクションとデータの整合性を維持および監視していることを確認します。
破損対策レイヤーで、異なるサブシステム間のすべての通信を処理する必要があるか、機能のサブセットのみを処理する必要があるかを検討します。
破損対策レイヤーがアプリケーション移行戦略の一部である場合は、それが永続的か、またはすべてのレガシ機能を移行した後で廃止する予定かを検討します。
前の図では、個別のサブシステムを使用してこのパターンを示していますが、モノリシック アーキテクチャでのレガシ コード統合など、他のサービス アーキテクチャにも適用できます。
破損対策レイヤーは、異なる信頼レベルを持つ可能性のあるシステムを仲介するため、この境界で入力の検証とサニタイズを適用することを検討してください。
変換エラーを診断するために、相関 ID や構造化ログなどの可観測性を計画します。
このパターンを使用する場合
このパターンは次の状況で使用します。
移行は複数のステージで行われる予定ですが、新しいシステムとレガシ システムの統合を維持する必要があります。
2 つ以上のサブシステムのセマンティクスは異なりますが、通信する必要があります。
このパターンは、次の場合に適さない場合があります。
- 新しいシステムとレガシ システムには、重要なセマンティックの違いはありません。 このシナリオでは、破損対策レイヤーを翻訳ロジックに集中することが重要です。 ビジネス ルールやオーケストレーションをレイヤーに配置しないでください。
ワークロード設計
ワークロードの設計で、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、アンチコラプション レイヤー パターンをどのように使用するかを評価します。 次の表は、このパターンが各柱の目標をサポートする方法に関するガイダンスを示しています。
| 支柱 | このパターンが柱の目標をサポートする方法 |
|---|---|
| オペレーショナルエクセレンス は、標準化されたプロセスとチームの結束によってワークロードの品質を提供します。 | このパターンは、これらのレガシ システムと統合する際に、異なるデータモデルやビジネスルールを持つ可能性があるレガシ実装によって、新しいコンポーネント設計が影響を受けないようにするのに役立ちます。 既存のコンポーネントをサポートしながら、新しいコンポーネントの技術的負債を削減できます。 - OE:04 ツールとプロセス - OE:07 監視システム |
このパターンによって柱内にトレードオフが生じる場合は、他の柱の目標に照らして検討してください。
Example
このパターンは概念であり、ドメイン駆動型の設計ソフトウェア開発アプローチに由来します。 Azure API ManagementやAzure FunctionsなどのサービスAzure、プロトコルの処理と翻訳に役立つ場合がありますが、破損防止レイヤーの主な目的は、特定の製品の選択を規定するのではなく、ドメイン モデルを保護することです。
次の例では、API Management が外部への公開とプロトコルの問題を処理します。 Azure Functionsは、新しいシステムとレガシ システムの間のドメイン マッピングを通じて破損対策レイヤーを実装します。 Azure Monitorと Application Insights は、2 つのサブシステム間の変換の成功と待機時間を追跡するために必要な可観測性を提供します。
この同期要求応答モデル以外にも、破損対策レイヤーでは、非同期のイベント ドリブン アプローチを使用することもできます。 レイヤーは、Azure Service Bus、Azure Event Grid、またはAzure Event Hubsを使用して、レガシ システムのスループット制約から最新ドメインを分離して、高スループットまたは高度に分離されたワークロードに対するメッセージベースの変換を可能にします。
次のステップ
分散トランザクションを管理し、補正トランザクション パターンや Saga 分散トランザクション パターンなどのデータ整合性 を 維持するのに役立つクラウド設計 パターンについて説明します。
破損対策レイヤーは単一障害点になる可能性があるため、 再試行パターン、 サーキット ブレーカー パターン、 バルクヘッド パターン、 正常性エンドポイント監視パターンを使用して回復性を計画します。