あなたのアプローチと分析は、解決しようとしているビジネス上の問題に関連するサービス機能を維持するのが妥当であるように思われます。顧客関連の機能は顧客サービスなどに組み込まれます。ただし、意思決定プロセスを強化し、直感的なアプローチを取り除く必要があります。
あなたが言及しているのは、SOAガバナンスと呼ばれるより大きなトピックのSOA設計時ポリシーの一部と呼ばれています。たくさんの Web サービスを持っているだけではアーキテクチャが SOA ではなくサービスベースになるわけではないので、SOA アーキテクチャに飛び込む前に SOA ガバナンスをセットアップするという苦労を経験することが不可欠です。私はこれが整っていないと仮定していることに注意してください。
SOA ガバナンス ポリシーは、サービスの設計方法を指定します。典型的な SOA 設計時のポリシーは、サービス設計に関して次のようになります。
再利用可能な設計。
サービスを設計するとき、このサービスが他のサービスやコンシューマによって再利用されるとよいでしょう。
SOA システムとそれが提供するすべてのサービスを見ると、サービスがさまざまなレベルの粒度を提供していることに気付くでしょう。エンティティの単一のプロパティを変更できるサービスから、ローンを申請できるサービスまで、何でも利用できます。では、なぜこの粒度が重要なのでしょうか? サービスの粒度によって、再利用のしやすさが決まります。
粒度の細かいサービスは、多くの場合、粒度の粗いサービスよりも簡単に再利用できます。この粒度を分割する方法の例を次に示します。
プロセス サービス: プロセス サービスは最も粒度の粗いサービスです。これらの種類のサービスは、ほとんどの場合、消費者にサービスまたは製品を提供します。典型的なプロセス サービスの例は、車の販売のようなものです。このシナリオでは、販売システムを更新する必要があり、在庫システムを更新する必要があり、さらに多くのシステムがこのトランザクションに関与しています。プロセス サービスは、そのタスクを実行するために他のサービスを呼び出します。通常、多くのサービス間でオーケストレーションを行う場合、プロセス サービスを扱っています。
ビジネス サービス: ビジネス サービスは、システムに単一の特定のビジネス機能を提供します。たとえば、車の販売に関する請求書と税務書類を使用して販売システムを更新します。
技術サービス: 最もきめ細かいサービスは技術サービスです。技術サービスは、特定の機能の一部を他のサービスに提供します。この例は、フロアの車の在庫を更新するサービスです。つまり、データベース内の車を販売済みとしてマークします。他の例としては、電子メールを送信したり、レガシー バックエンドを呼び出したりします。
また、サービスのカタログを保持する必要があります。このカタログは、サービスの重複を排除するために、サービスとその機能を最新の状態に保つ必要があります。また、サービス機能を定義する必要がある場所を決定することもできます。
サービスのカタログと設計時のポリシーを使用すると、機能を配置する場所を決定できます。
SOA にまつわる管理全体を扱っているので、この本をお勧めします。どの正式な方法論を使用するかについては、それらを試して、自分に合った方法を維持することをお勧めします. 意思決定チームにビジネス担当者がいると、ビジネスを理解しているため、機能がどこにあるべきかについての洞察を得るのに役立つことに注意してください。それを SOA ガバナンス ポリシーで正式化し、それらのポリシーを 8 ～ 12 か月ごとに見直して、それらがまだ関連性があり、機能していることを確認してください。