古くなったシステムをどうやって置き換えるのか
こんにちは。
多くの方が古くなったシステムに頭を悩まされていることだと思います。
ただ古いからと言っていざ置き換えるとなると「言語どうする？」「置き換えるのにどんだけ時間かかるんだ？」「安全に移行できるのだろうか？」など不安は尽きないですよね。
自分が調べたところでいくつか置き換える方法が見つかったのでまとめておこうと思いました。
パターン
泥団子になったものを一挙にすべて置き換えるのは多くのシステムは難しいのが現状です。
そのために少しずつ移行するパターンです。
ストラングラーフィグパターン
このパターンは前からよく目にしますね。
マイクロソフトのアーキテクチャセンターにも書いてあります。
泥団子になったシステムの前段にゲートウェイを置いてフロントからはファサードを通して切り替わることを意識せずに移行する手法です。
ファサードで古いシステムと新しいシステムをルーティングして、徐々に置き換えていくものです。
レガシーミミック
原文は英語ですがこちらになります。
サイトにもある通り DDD の腐敗防止層を設けるのと似ているみたいです。
UI のイベントを Event Interceptor Mimic でインターセプトして徐々に移行するパターンのようです。
インターセプト先の新しいロジックでは Legacy Mimic を設けて部分的に古いシステムのデータを見るようです。
手法
いざ移行するとなった場合にどこから手をつければよいのだ？
というときに「ソフトウェアアーキテクチャ・ハードパーツ」という本に紹介されていました。
泥団子を移行するときには基本的に「準備」が大事なようです。
手法として「コンポーネントベース分解」と「戦術的フォーク」の大きく二つ記載されていました。
コンポーネントベース分解
本にある内容として大きく下記の流れでパターンが分類されていました。
- コンポーネントの特定およびサイズ調整パターン
- モノリシックアプリケーションを分解
- コンポーネントを特定し、適切なサイズを見極める
- ドメイン共通コンポーネントの収集パターン
- アプリケーション全体で重複している可能性のある、ビジネスドメインの共通ロジックを統合
- コンポーネントのフラット化パターン
- ドメインやサブドメイン、コンポーネントをまとめたり拡張したりする
- 必要なソースコードがうまく定義されたコンポーネント内にのみ存在するようにする
- コンポーネントの依存関係判断パターン
- コンポーネントの依存関係を特定
- 依存関係を改善し、分散アーキテクチャへの移行実現性と全体的なコストを判断
- コンポーネントドメインの作成パターン
- コンポーネントをアプリケーション内の論理的なドメインにグループ化
- 名前空間やディレクトリを特定のドメインに合わせてリファクタリングする
- ドメインサービスの作成パターン
- 論理ドメインを個別にデプロイされたドメインサービスに移動する
- 物理的に分離する
既存システムを丸裸にして独立したサービスにした上で移行していくパターンのようです。
戦術的フォーク
このパターンはコンポーネントベース分解とは逆にパターンをとっていきます。
まずは同一資源をコピーした上で、チームごとにコピーされた資源から不要なものをどんどん消していって、最後のこったものがサービスとして使用していくパターンです。
本にこのパターンはあまり触れられていなかったですが、とっつきは入りやすいものの、重複したロジックが最後残ったりリスクは結構伴いそうな印象でした。
さいごに
既存資源のお守りって大変ですよね。
だけど前に進むしかないと思っているので、その中でできることとか探していきたいです。
Discussion