抽象化による分岐パターン

strangler fig パターンは、モノリスの周囲で呼び出しをインターセプトできる場合に適しています。ただし、レガシーアプリケーションスタックのより深いところに存在し、上流に依存するコンポーネントをモダナイズしたい場合は、抽象化による分岐パターンをお勧めします。このパターンを使うと、既存のコードベースに変更を加え、モダナイズしたバージョンを中断することなくレガシーバージョンと安全に共存させることができます。

抽象化による分岐パターンを正常に使用するには、次のプロセスに従います。

1. アップストリームに依存するモノリスコンポーネントを特定します。

2. モダナイズするコードとそのクライアントとのやり取りを表す抽象化レイヤーを作成します。

3. 抽象化が完了したら、既存のクライアントを新しい抽象化を使用するように変更します。

4. モノリスの外部で機能を作り直して、抽象化の新しい実装を作成してください。

5. 準備ができたら、新しい抽象化を実装に切り替えます。

6. 新しい実装でユーザーに必要な機能がすべて提供され、モノリスが使用されなくなったら、古い実装をクリーンアップします。

抽象化による分岐パターンは、特徴量の切り替え と混同されがちです。特徴量の切り替えを使用すると、システムを段階的に変更することもできます。違いは、特徴量の切り替えは新しい特徴量の開発を可能にし、システムの稼働中はそれらの特徴量をユーザーには見えないようにすることを目的としている点です。そのため、特徴量の切り替えはデプロイ時またはランタイム時に使用され、特定の特徴量または特徴量のセットをアプリケーションに表示するかどうかを選択します。抽象化による分岐パターンは開発手法であり、特徴量の切り替えと組み合わせて古い実装と新しい実装を切り替えることができます。

以下の表は、抽象化による分岐パターンを使用することの利点と欠点について説明します。

利点	欠点
何か問題が発生した場合に元に戻せるように、段階的に変更を加えることができます ( 下位互換性あり )。 モノリスのエッジで呼び出しをインターセプトできない場合に、モノリスの奥深くにある機能を抽出できます。 ソフトウェアシステム内で複数の実装を共存させることができます。 中間検証ステップを使用して新しい機能と古い機能の両方を呼び出すことで、フォールバックメカニズムを簡単に実装できます。 再構築段階の間ずっとコードが動作し続けるため、継続的な提供をサポートします。	データ整合性が関係する場合は適していません。 既存のシステムへの変更が必要です。 特にコードベースの構造が不十分な場合、開発プロセスのオーバーヘッドが増える可能性があります。( 多くの場合、余分な労力をかけるだけのメリットがあり、再構築が大きくなればなるほど、抽象化による分岐パターンの使用を検討することがより重要になります )。

以下の図は、保険モノリスの通知コンポーネントの抽象化による分岐パターンを示したものです。まず、通知機能用の抽象化またはインターフェイスを作成します。既存のクライアントは、新しい抽象化を使用するように少しずつ変更されます。そのためには、通知コンポーネントに関連する API の呼び出しをコードベースで検索する必要があるかもしれません。通知機能の新しい実装をモノリスの外部にあるマイクロサービスとして作成し、モダナイズされたアーキテクチャでホストします。モノリスの内部では、新しく作成した抽象化インターフェイスがブローカーの役割を果たし、新しい実装を呼び出します。通知機能を少しずつ新しい実装に移植し、完全にテストされて準備が整うまで非アクティブのままになります。新しい実装の準備ができたら、それを使用するように抽象化を切り替えます。問題が発生した場合に古い機能に簡単に切り替えることができるように、簡単に切り替えられる切り替えメカニズム ( 特徴量の切り替えなど ) を使用したいと思うでしょう。新しい実装ですべての通知機能がユーザーに提供され始め、モノリスが使用されなくなったら、古い実装をクリーンアップして、実装していた可能性のある特徴量の切り替えフラグをすべて削除できます。