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