これまでの十四章
プロジェクトがすでに進行中の場合
プロジェクト進行中にパターンを取り入れるケースです。
まずは、現在の境界づけられたコンテキストを定義する。現状を把握することです。
次に、継続的な統合を改善すること。どこかに変換コードがあれば、腐敗防止層を作成しまとめること。
現状を整理するのが最初のステップ。これが出来てから、次の作戦へ。
１回のイテレーションでは、変換が大きすぎて対応できないので、ステップ分割して進めます。
別々の道から共有カーネルへ
小さなサブドメインを選択して、両方のコンテキストで重複するものから着手する。必ずテストコードを書くこと。１週間に一度は統合することが大事です。
なんとなく、ここまでするなら別々の道の方がいい気もしますが、統合を目指すなら少しずつ着手していきましょう。
両チームのメンバーから集まったグループが統合を進めていきます。
共有カーネルから継続的な統合へ
コアドメインを統合していく。チーム間でメンバのローテンションをし、両方のモデルを理解している人を増やしていく。
統合の頻度は１日に１度にしていく。
次は別のケース。レガシーシステムを廃止していくケースです。
レガシーシステムを段階的に廃止する。
1回のイテレーションで移行できるような、レガシーシステムの特定の機能を識別して、腐敗防止層を併用しながら段階的にレガシーシステムを廃止していく手法です。
レガシーシステムで現在使用していないモジュールを全体が切り替わるまで稼働させておくのがポイント。
粗末な設計のソフトウェアだと、一度に切り離すのが難しく、使用していないとわかっていても、稼働させておくのが現実的。
上記を何度も繰り返すことで、段階的にレガシーコードがビジネスにかかわらなくなり、切り離すことができるようになる。
レガシーを稼働しながら、新システムへ移行していくので、腐敗防止層は収縮したり、膨張したりする。
・・・ということですが、できるものでしょうか。。。というのが感想ですが、一気に移行しようとすると、レガシーで設計がまずいシステムではそれを解析するだけで何年もかかってしまう。。。というのは経験しています。
なので、腐敗防止層を使って段階的に配する方法について、検討する価値自体はあるかと思います。