サービス粒度の原則

ソフトウェア エンジニアリングとソフトウェア アーキテクチャのコンテキストでは、サービス粒度は​​、サービス指向モデリングなどのサービス指向のパラダイムを適用する際の重要な設計上の考慮事項です。サービス粒度は​​、サービス指向アーキテクチャ (SOA)内で提供されるサービス操作におけるビジネス機能の範囲とメッセージ ペイロードの構造を指定します。

サービス粒度は​​、アプリケーション ドメインの問題 (ビジネス粒度) であると同時に、ソフトウェア インターフェイス設計の問題 (技術的粒度) でもあります。これは、サービス プロバイダーによって公開されるサービスコントラクトのプロパティです。これは、受信 (要求) および送信 (応答) メッセージ コンテンツのセマンティクスと構文に関係し、2 つの一般的なエンタープライズ統合パターン、コマンド メッセージとドキュメント メッセージのインスタンスとして見ることができます。定義上、粗粒度のサービス操作は、細粒度のサービスよりも範囲が広くなりますが、用語は相対的です。前者は通常、設計の複雑さが増しますが、タスクを完了するために必要な呼び出しの数を減らすことができます。^[1]

分散コンピューティングの誤りのため、適切な粒度を見つけることは困難です。^[2]単一の単純な答えはありませんが、いくつかの基準が存在します（以下を参照）。サービスモデリングと粒度設計の主な目標は、 SOAの重要な原則の2つである疎結合とモジュール性を実現することと、^{[3]その他の}アーキテクチャ的に重要な要件に対処することです。

サービスの粒度には多くの要因が影響します。^[4]適切な粒度を設計する際に特に考慮すべき4つの要素は、パフォーマンス、メッセージサイズ、トランザクション性、ビジネス機能です。

理想的には、各サービス操作は単一のビジネス機能にマップされますが、設計の複雑さを増したりメッセージ サイズを大きくしたりすることなく単一の操作で複数の機能を提供できる場合は、この汎用性により実装および使用コストを削減できます。

Web サービスはリモートでアクセスされ、Web サービス操作の呼び出しによってネットワーク オーバーヘッドが増加します。サービス要求の数を減らすと、そのオーバーヘッドが削減されます。

粗粒度のサービスでは、タスクに特に必要ではないデータを含め、細粒度のサービスよりも多くのデータが渡される可能性があります。これにより、エンドポイントでのメッセージ処理が複雑になり、パフォーマンスが低下する可能性があります。メッセージ サイズを縮小するには、より細粒度の操作の追加が必要になる場合があります。

概念を明確にするために、各サービス操作は単一のシステム レベルのトランザクションを実行し、サービス境界を越えたデータの整合性をサービス コンシューマーのビジネス ロジックに委ねる必要があります。これにより、エラー回復も簡素化され、通常は設計が容易になります。

適切な粒度を見つけるための決定基準は他にもたくさん存在しますが、全体最適というものはありません。そのような結合基準16個が文献から集められています。^[5]

1 つのサイズですべてに対応できるわけではないため、サービス粒度の設計では、さまざまな分散システム、特にサービスに関連する多くの既存のパターン作業や、API 設計 (オブジェクト指向プログラミングでの API 設計など) およびエンタープライズ統合に関連するパターン作業の恩恵を受けることができます。ここでは、そのような言語の概要を示します。

• 概念的なサービス粒度フレームワーク
• サービス用語集のサービス粒度エントリ
• クッキングEA - サービスの粒度
• SOA 実現の成功におけるサービス粒度の役割に関する IEEE ケース スタディ
• SOA インフラストラクチャ リファレンス アーキテクチャにおけるアーキテクチャ知識 (SOA ケース スタディ)
• 「Web サービスの粒度を適切に設定する」では、サービス粒度の原則に関する情報と、それを適切に設定するための役立つアドバイスが提供されます。
• SOA実践ガイド
• サービスの粒度に関する課題の解決
• 粗粒度のインターフェース
• SOA サービスの粒度を評価するためのメトリクス フレームワーク
• GitHub 上のサービス カッター ツールと結合基準カタログ