大規模なレガシー置き換えはIT業界における苦行だ。Thoughtworksの主任コンサルタントのBrandon Byars氏はこう言って、大規模なレガシー置き換えプロジェクトでRESTful統合を使った経験について語った。
Brandon氏はこうしたプロジェクトの多くで、REST over HTTPを使うのが魅力的な選択肢になると考えている。これは使いやすく、理解しやすく、巨大なフレームワークを必要としないためだ。アーキテクチャ上、RESTはスケーラブルであり、ドメインモデリングにフィットすることがわかっていると彼は考えている。しかし、RESTに関する議論は、ささいな詳細に陥りがちだ。プロジェクトの成功を確実にするため、彼がより重要だと考えているのは、そのデプロイメント戦略やテスト戦略としての側面だ。
Brandon氏の最初のアドバイスは、論理的な環境を使って、さまざまなチームや役割のニーズを満たすことだ。
論理的な環境とは、ビジネスや開発ニーズを満たすのに必要とされる、適切に独立した、相互に関係のあるアプリケーション、サービス、基盤コンポーネントの集合です。
そうして、彼はさまざまな環境に取り組んでメンテナンスしてきた経験から、役に立つことがわかったテクニックについて説明した。彼が反論しているものの1つは環境のバージョニングだ。これはシステムとの連携をかなり複雑にするおそれがあると彼は考えている。
Brandon氏の経験によると、アーキテクトがやってしまう最も高くつく間違いの1つは、データ境界がきちんと定義されていないことだ。よく見られるアンチパターンは、エンティティに関するすべての情報を単一のデータストアに格納して、必要に応じてエクスポートするという戦略だ。これはマスターデータ管理(MDM)の表面的な誤解によって引き起こされていると彼は考えている。それに対して、彼の解決策は、ドメイン駆動設計(DDD)の概念である境界づけられたコンテキスト内に各チームの定義をラップし、その用語が使われるときはいつも同じものを意味するというものだ。
各ビジネスユニットは、境界づけられたコンテキスト間の明確な翻訳を備えた共通のエンティティについて、異なるモデルを持っています。
彼はまた、分散システムに取り組むときには、ハイレベルなフィーチャに関するユーザーストーリーをエピックにまとめ、そのエピックを使って進捗を計測することを推奨している。これにより進捗の錯覚を避けることができる。たいていのストーリーはチームが約束通りに行うことを示すことで完了となるが、わずかなストーリーが足らないためにフィーチャーはデモできなくなるためだ。
プログラムレベルのメトリクスは、ベロシティを追跡する主要メトリックとしてエピックを保持します。チームのユーザーストーリー・ベロシティは進捗の錯覚をもたらすおそれがあります。
Brandon氏は、RESTfulサービスを使った戦略を支持しており、それがよりシンプルな開発を促すと信じているが、RESTは決して銀の弾丸ではないことを強調して話を締め括った。