BT

RESTを使ったエンタープライズ統合から学んだこと

| 作者: Jan Stenberg フォローする 34 人のフォロワー , 翻訳者 笹井 崇司 フォローする 0 人のフォロワー 投稿日 2013年12月3日. 推定読書時間: 2 分 |

原文(投稿日:2013/11/28)へのリンク

大規模なレガシー置き換えはIT業界における苦行だ。Thoughtworksの主任コンサルタントのBrandon Byars氏はこう言って、大規模なレガシー置き換えプロジェクトでRESTful統合を使った経験について語った
Brandon氏はこうしたプロジェクトの多くで、REST over HTTPを使うのが魅力的な選択肢になると考えている。これは使いやすく、理解しやすく、巨大なフレームワークを必要としないためだ。アーキテクチャ上、RESTはスケーラブルであり、ドメインモデリングにフィットすることがわかっていると彼は考えている。しかし、RESTに関する議論は、ささいな詳細に陥りがちだ。プロジェクトの成功を確実にするため、彼がより重要だと考えているのは、そのデプロイメント戦略やテスト戦略としての側面だ。

Brandon氏の最初のアドバイスは、論理的な環境を使って、さまざまなチームや役割のニーズを満たすことだ。

論理的な環境とは、ビジネスや開発ニーズを満たすのに必要とされる、適切に独立した、相互に関係のあるアプリケーション、サービス、基盤コンポーネントの集合です。

そうして、彼はさまざまな環境に取り組んでメンテナンスしてきた経験から、役に立つことがわかったテクニックについて説明した。彼が反論しているものの1つは環境のバージョニングだ。これはシステムとの連携をかなり複雑にするおそれがあると彼は考えている。

Brandon氏の経験によると、アーキテクトがやってしまう最も高くつく間違いの1つは、データ境界がきちんと定義されていないことだ。よく見られるアンチパターンは、エンティティに関するすべての情報を単一のデータストアに格納して、必要に応じてエクスポートするという戦略だ。これはマスターデータ管理(MDM)の表面的な誤解によって引き起こされていると彼は考えている。それに対して、彼の解決策は、ドメイン駆動設計(DDD)の概念である境界づけられたコンテキスト内に各チームの定義をラップし、その用語が使われるときはいつも同じものを意味するというものだ。

各ビジネスユニットは、境界づけられたコンテキスト間の明確な翻訳を備えた共通のエンティティについて、異なるモデルを持っています。

彼はまた、分散システムに取り組むときには、ハイレベルなフィーチャに関するユーザーストーリーをエピックにまとめ、そのエピックを使って進捗を計測することを推奨している。これにより進捗の錯覚を避けることができる。たいていのストーリーはチームが約束通りに行うことを示すことで完了となるが、わずかなストーリーが足らないためにフィーチャーはデモできなくなるためだ。

プログラムレベルのメトリクスは、ベロシティを追跡する主要メトリックとしてエピックを保持します。チームのユーザーストーリー・ベロシティは進捗の錯覚をもたらすおそれがあります。

Brandon氏は、RESTfulサービスを使った戦略を支持しており、それがよりシンプルな開発を促すと信じているが、RESTは決して銀の弾丸ではないことを強調して話を締め括った。

この記事に星をつける

おすすめ度
スタイル

こんにちは

コメントするには InfoQアカウントの登録 または が必要です。InfoQ に登録するとさまざまなことができます。

アカウント登録をしてInfoQをお楽しみください。

あなたの意見をお聞かせください。

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする
コミュニティコメント

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

HTML: a,b,br,blockquote,i,li,pre,u,ul,p

このスレッドのメッセージについてEmailでリプライする

ディスカッション

InfoQにログインし新機能を利用する


パスワードを忘れた方はこちらへ

Follow

お気に入りのトピックや著者をフォローする

業界やサイト内で一番重要な見出しを閲覧する

Like

より多いシグナル、より少ないノイズ

お気に入りのトピックと著者を選択して自分のフィードを作る

Notifications

最新情報をすぐ手に入れるようにしよう

通知設定をして、お気に入りコンテンツを見逃さないようにしよう!

BT