mcpField
L
legacy-modernizer

legacy-modernizer

github.com/404kidwiz開発88 回インストール
リポジトリ

legacy-modernizer について

レガシーシステムを全面的に書き換えず、段階的に近代化するチーム向けのスキルです。トラフィックの切り替え、システム境界の分離、データ同期の移行パターンを扱います。

主な機能

  1. 01段階的な移行ロードマップの策定
  2. 02Strangler Fig と抽象化パターンの適用
  3. 03腐敗防止層によるドメインモデルの分離
  4. 04CDC による移行データの同期
  5. 05優先順位の評価とロールバック計画

活用シーン

  1. 01モノリスを段階的にマイクロサービス化
  2. 02新旧システム間のデータ同期
  3. 03互換性を保ちながらレガシー API を置換
  4. 04移行中の二重書き込みとトラフィック切り替え

インストール

コマンドをコピーしてターミナルで実行します。

$npx skills add https://github.com/404kidwiz/claude-supercode-skills --skill legacy-modernizer

インストール後、Claude Code で/legacy-modernizerを入力して読み込まれたか確認します。

詳細

レガシーシステムのモダナイゼーション

目的

システムを全面的に書き換えることなく、レガシーシステムを段階的にモダナイズするための専門知識を提供します。ストラングラーフィグ、変更データキャプチャ（CDC）、腐敗防止層などの移行パターンを専門とし、事業継続性を維持しながらシステムを安全に進化させます。

使用する場面

  • モノリスからマイクロサービスへの移行を計画する
  • ストラングラーフィグパターンを実装する
  • 旧システムと新システムの間に腐敗防止層を設計する
  • データ同期のために変更データキャプチャを設定する
  • レガシーデータベースを段階的にモダナイズする
  • 互換性を維持しながらレガシー API を置き換える
  • モダナイゼーションの優先順位を決めるためにレガシーコードベースを評価する
  • 移行中のデュアルライトのシナリオを管理する

クイックスタート

次の場合にこのスキルを呼び出します：

  • レガシーモノリスを最新のアーキテクチャに移行する
  • ストラングラーフィグまたはブランチ・バイ・アブストラクションを実装する
  • 腐敗防止層を設計する
  • システム間のデータ同期のために CDC を設定する
  • 段階的なモダナイゼーションのロードマップを計画する

次の場合は呼び出さないでください：

  • グリーンフィールドのマイクロサービス設計 → /microservices-architect を使用します
  • 移行を伴わない一般的なリファクタリング → /refactoring-specialist を使用します
  • 移行を伴わないデータベースの最適化 → /database-optimizer を使用します
  • レガシーシステムに関する考慮が不要な API 設計 → /api-designer を使用します

判断フレームワーク

Migration Strategy?
├── Replace Incrementally
│   └── Strangler Fig: Route traffic to new service gradually
├── Abstract and Replace
│   └── Branch by Abstraction: Interface → implement new → switch
├── Data Sync Required
│   └── CDC with Debezium/similar for real-time sync
└── Protect New from Old
    └── Anti-Corruption Layer: Translate between domains

主なワークフロー

1. ストラングラーフィグの実装
  1. 切り出す境界づけられたコンテキストを特定します
  2. レガシーシステムの前面にファサード／プロキシを作成します
  3. 同じインターフェースを実装する新しいサービスを構築します
  4. トラフィックの一部を新しいサービスにルーティングします
  5. 新しいサービスに流すトラフィックの割合を徐々に増やします
  6. 移行が完了したらレガシーコンポーネントを廃止します
2. 腐敗防止層のセットアップ
  1. 新しいシステム用のクリーンなドメインモデルを定義します
  2. レガシーシステムとの統合ポイントを特定します
  3. モデル間の変換レイヤーを構築します
  4. レガシー API／データ用のアダプターを実装します
  5. 変換の失敗を監視する仕組みを追加します
  6. マッピングルールを文書化します
3. CDC によるデータ移行
  1. CDC ツール（Debezium、AWS DMS）をセットアップします
  2. レガシーデータベースで変更キャプチャを設定します
  3. 新しいシステムに変更を適用するコンシューマーを構築します
  4. 変換を使ってスキーマの違いに対処します
  5. 検証と照合作業を実装します
  6. 切り替えとフォールバックの戦略を計画します

ベストプラクティス

  • 段階的に移行し、一括書き換えは避けます
  • 移行中も機能の同等性を維持します
  • フィーチャーフラグを使ってトラフィックのルーティングを制御します
  • 移行中は包括的な監視を実施します
  • 切り替えが完了するまでレガシーシステムと新システムの同期を保ちます
  • すべての統合ポイントと依存関係を文書化します

アンチパターン

アンチパターン問題正しいアプローチ
一括書き換えリスクが高く、期間も長い段階的な移行
腐敗防止層がない新しいシステムがレガシーの影響を受けるACL で分離する
CDC を使わないデュアルライトデータの不整合同期には CDC を使う
すべてを一度に移行する複雑さに圧倒されるビジネス価値に基づいて優先順位を決める
ロールバック計画がない移行に失敗すると身動きが取れなくなる常にフォールバックを計画する

コメント

Markdown 対応