既存のモノリシックRails3.0アプリケーション（35K LOC）を採用し、それをSOA設計に分解するためのリソースを探しています。どんな本、ブログ、スクリーンキャスト、またはサンプルアプリケーションも素晴らしいでしょう。
私が答えようとしている主な質問は次のとおりです。
私が見たいくつかのリソースですが、それらが開始するのに適切な場所であるかどうかは完全にはわかりません。
SOAは適切な設計でさえありますか？
場合によります。こういう答えが嫌いじゃないですか。メッセージングまたはAPI呼び出しを使用してアプリを疎結合サービスに分割すると、定義上、SOAが実装されます。
その利点は、インターフェースを変更せずにサービスの実装を交換でき、アプリ全体を停止することなく独立したデプロイができることです。また、認証されたユーザーまたはロールベースのセッション用に予約する状態全体ではなく、バージョン管理されてカスタム状態を公開する専用のAPIコントローラーを介してSOAを実装します。
私の経験からのジレンマは、同期呼び出しと非同期呼び出しのどちらを実装するかです。同期呼び出しは明らかにプログラミングが簡単ですが、実行中にユーザーがハングしたままになる可能性があり、長時間実行されるクエリのタイムアウトを処理する必要があります。データベースとWebサーバーのタイムアウトに注意してください。
非同期呼び出しを実装する場合、たとえばActiveMessagingなどを介して、ユーザーにバブルアップするためにコールバックまたはある種の通知を処理する必要があります。また、ステータスを確認するために、プライマリおよびセカンダリメッセージブローカーと、JavaScriptまたはポーラーを設定する必要があります。でもそれはすべて楽しいです！
どこから始めればいいですか？
最初に、それが「価値がある」かどうかを確認します。結局のところ、SOAは優れていますが、現在はない複数の障害点が発生します。分割されたアプリがHAであり、他のプロジェクトにサービスを提供する個別のサービスになると思われる場合は、おっしゃるように「drubybook」と「serviceoriented」から始めます。
回避できる一般的な落とし穴は何ですか？
最大の懸念は、複数のサービスにまたがるトランザクションと、離れたサービスに障害が発生した場合に操作全体をロールバックする機能だと思います。問題は、Aを呼び出し、Bを呼び出し、BがCを呼び出し、Cが失敗する操作を行っている場合に始まります。Cが失敗したことを誰が知っていますか？BとAにロールバックするようにどのように指示しますか？彼らはできますか？彼らは状態を保存しますか？先行設計に関する難しい質問。
もう1つの問題は、SOAの上にワークフローを配置すると、作業が複雑になることです。ビジネスプロセスの管理者は誰ですか。一元化または分散？それはすべて絶対にクールなものですが、重さは忍び寄りますね？しかし、SOAに移行しなければならないのであれば、それが人生です。
今何を考えるべきか、後で何ができるか？（つまりパフォーマンス）
現在、他のアプリで使用できる明らかな汎用サービスを除外します。障害点の追加を回避し、SOAが導入する障害点を最小限に抑えるために、環境を過度にSOAすることはしません。
これは、CrowdtapのCTOである私の友人からの優れたリソースです。彼らは同じことをしました、そしてそれは彼らが製品開発の速度を大いに改善しそして彼らにより良いテストカバレッジを与えるのを本当に助けました。https://www.youtube.com/watch?v=KsiQXAXsQDQに役立つことを願っています