同じセマンティクスを共有しない異なるサブシステム間にファサード、つまりアダプター レイヤーを実装します。 このレイヤーでは、一方のサブシステムがもう一方のサブシステムに行った要求が変換されます。 このパターンを使用することで、アプリケーションの設計が、外部サブシステムへの依存関係によって制限されないようにします。 このパターンは、Eric Evans が『Domain-Driven Design』で初めて説明しました。
コンテキストと問題
アプリケーションのほとんどが、そのデータや機能の一部について、他のシステムに依存しています。 たとえば、レガシ アプリケーションを最新のシステムに移行するとき、そのレガシ アプリケーションは、引き続き既存のレガシ リソースを必要とする可能性があります。 レガシ システムは、新しい機能で呼び出すことができなければなりません。 これは、特に、段階的な移行の場合に当てはまります。こうした移行では、大規模なアプリケーションのさまざまな機能が、時間をかけて最新システムに移動します。
このようなレガシ システムには、多くの場合、データ スキーマが複雑、API が古いなど、品質に関する問題があります。 レガシ システムで使用されている機能とテクノロジは、最新のシステムとは大きく異なる可能性があります。 レガシ システムと相互運用するには、新しいアプリケーションには、最新アプリケーションに組み込まない古いインフラストラクチャ、プロトコル、データ モデル、API、またはその他の機能のサポートが必要になることがあります。
新しいシステムとレガシ システムの間のアクセスを維持することによって、新しいシステムは、少なくともレガシ システムの API または他のセマンティクスの一部に強制的に従うことになります。 こうしたレガシ機能の品質に問題がある場合、その機能をサポートすることで、正常に設計された最新のアプリケーションが "破損" する場合があります。
レガシ システムだけでなく、開発チームが制御できない外部システムでも似た問題が発生する可能性があります。
解決策
異なるサブシステムの間に破損対策レイヤーを配置し、これらを切り離します。 このレイヤーは、2 つのシステム間の通信を変換するもので、一方のシステムはそのままで、もう一方のシステムの設計と技術的アプローチも損なわれません。
上記の図は、アプリケーションと 2 つのサブシステムを示しています。 サブシステム A は、破損対策レイヤーを通じてサブシステム B を呼び出します。 サブシステム A と破損対策レイヤーの間の通信では、常に、サブシステム A のデータ モデルとアーキテクチャが使用されます。破損対策レイヤーからサブシステム B への呼び出しは、そのサブシステムのデータ モデルまたはメソッドに準拠します。 破損対策レイヤーには、2 つのシステム間の変換に必要なロジックがすべて含まれます。 レイヤーは、アプリケーション内でコンポーネントとして実装できます。また、独立したサービスとして実装することもできます。
問題と注意事項
- 破損対策レイヤーにより、2 つのシステム間で行われた呼び出しで、待ち時間が追加される場合があります。
- 破損対策レイヤーにより、管理および保守しなければならない追加サービスが増えます。
- 破損対策レイヤーをスケールする方法を検討してください。
- 複数の破損対策レイヤーが必要かどうかを検討してください。 さまざまなテクノロジや言語を使用して、機能を複数のサービスに分解できます。破損対策レイヤーをパーティション分割する理由が他に存在する可能性もあります。
- 他のアプリケーションまたはサービスとの関係で、破損対策レイヤーがどのように管理されるかを考慮してください。 これは、監視、リリース、および構成プロセスにどのように統合されますか。
- トランザクションおよびデータの整合性は保持され、監視できることを確認してください。
- 破損対策レイヤーが処理する必要があるのが、異なるサブシステム間のすべての通信か、または機能のサブセットのみかを検討してください。
- 破損対策レイヤーがアプリケーション移行戦略の一部である場合は、そのレイヤーを永続的に使うか、すべてのレガシ機能が移行された時点で使用をやめるのかを検討します。
- このパターンは、上記の個別のサブシステムで示されていますが、レガシ コードをモノリシック アーキテクチャに統合する場合など、他のサービス アーキテクチャにも適用できます。
このパターンを使用する状況
このパターンは次の状況で使用します。
- 複数の段階にわたって移行が発生するが、新しいシステムとレガシ システムの間の統合を保持する必要があるとき。
- 2 つ以上のサブシステムでセマンティクスが異なるが、通信する必要があるとき。
新しいシステムとレガシ システムの間で大きなセマンティクスの違いがない場合、このパターンは適切でない可能性があります。
ワークロード設計
設計者は、Azure Well-Architected Framework の柱で説明されている目標と原則に対処するために、ワークロードの設計における腐敗防止層パターンをどのように使用できるかを評価する必要があります。 次に例を示します。
| 重要な要素 | このパターンが柱の目標をサポートする方法 |
|---|---|
| オペレーショナルエクセレンス は、標準化されたプロセスとチームの結束によってワークロードの品質を提供します。 | このパターンを使用すると、新しいコンポーネント設計がレガシーシステムとの統合時に異なるデータモデルやビジネスルールを持つレガシー実装の影響を受けなくなります。また、既存のコンポーネントをサポートしながら、新しいコンポーネントの技術的な負債を削減できます。 - OE:04 ツールとプロセス |
設計決定と同様に、このパターンで導入される可能性のある他の柱の目標とのトレードオフを考慮してください。