マイグレーションプロジェクトやモダナイゼーションプロジェクトは、開発者が同じアプリケーションの異なるコンポーネントやバージョンに対処する必要がある2つの例に過ぎません。リファクタリングは頻繁に行われ、A/Bテスト、カナリアリリース、Blue/Greenデプロイメントなどのプラクティスを使用してこれらの異なるモデルをデプロイしますが、ほとんどの場合、アーキテクチャにはそれらと通信する他のコンポーネントがあり、後方互換性が必要となる場合があります。両方の構造が適切に動作するように維持するのは大変なことで、新しいデータを受け取りながら古いスキーマを新しい構成へ置き換え、すでにあるものを更新するのはさらに難しいことです。Expand/Contractパターンは、これらを行うための信頼性の高い３段階の移行パターンです。

レガシークライアントをブレークアウトせずに新しい構成へ移行させ、ユーザーに大きな影響がない状態でアプリケーションを完全に更新できるようにできます。

1st phase - Expand

最初のフェーズは”Expand（拡張）"と呼ばれます。ここでは、新しいコードを実装します。そうすることで、アプリケーションは新旧両方の実装をサポートすることができます。例えば、Shirt というテーブルがあり、このテーブルの中で、シャツの色を識別するために色の名前を使用しているとしましょう。デザイナーが”濃紺のシャツ”という意味で”青のシャツ”を要求したのに、”水色”が送られてきたことが何度かあったため、色の名前を識別のために使用すると、本番稼働中に問題が発生することがありました。この問題を解決するために、私たちはこのプロセスを変更し、色の名前を使う代わりに、これからは色の16進コードを使うことにします。

2nd phase - Transition

さて、新しいコードができたので、それをユーザー/クライアントに公開する必要があります。この時点で、両方の実装を動作させる"Transition（移行）"フェーズを開始します。こうすることで、新しいデータを新しくて”正しい”フォーマットで導入しつつ、古いデータと連携ポイントを適切に移行するための時間を確保することができます。このフェーズでは、データを新旧両方の方式で保存する必要があるため、冗長さに対処する必要があります。トリガー（DB機能のトリガー）を導入して、古いシステムにデータを保存し、トリガーがそれを変換して新しいスキームに保存できるようにすることもできます。これで自信がついたら、旧データベースから新データベースにデータを移行することができます。その際、冗長なデータを処理することを常に念頭に置いてください。移行したデータの整合性を確認し、古い構造からの読み込みを停止します。そして、このフェーズからの最後のステップは、古いスキームへの書き込みを停止することになります。

3rd phase - Contract

もう古い構造は使わないので、今度は”Contract（収縮）”フェーズを導入して、古いコードを構造から完全に削除します。シャツの例に戻りましょう。もう古い構造は使わないし、古いデータも適切に移行したので、colorName カラムを削除して colorCode だけを使用することができます。