アーキテクチャにおける粒度

この記事は、Peter Cripps氏による、「Architectural Granularity」を、ご本人の許可を得て翻訳したものです。*1


粒度の定義についての、古いジョークがある。

粒度はポルノとちょっと似ている。定義することは難しいが、見ればそれだとわかる。

ソフトウェア・コンポーネントの粒度に関するトピックは、いくつもの理由から、ソフトウェア・アーキテクトにとって重要なものである。

  • もしあなたが非常に多くの、細かい粒度のコンポーネントを作っている場合、それはアーキテクチャではなく、デザインである。
  • 以前の記事で述べたように、コンポーネントを正しいレベルの粒度にすることは、それらのコンポーネントをノードに配置し、可用性やパフォーマンスといった非機能要件を満たす際に重要となる。
  • コンポーネントの粒度は、パフォーマンスに影響を与える。非常に多くの、細かい粒度のコンポーネントは、ネットワークのトラフィックを増やすことになるだろう。それらのコンポーネントを使用するクライアントは、タスクを実行したり、必要な情報を取得するために、いくつもの問い合わせを行わなければならないからだ。
  • 一般的に言って、粒度が荒いほど、ビジネスに有用なものとの直接的な相関を持つようになる。(例えば、部屋の予約に関すること全てを行う”予約”コンポーネントは、”空き部屋を発見する”コンポーネントより有用である。)

”細かい粒度”、”一般的な粒度”、そして”荒い粒度”という用語は、しばしばアーキテクチャ的なコンポーネント(またはサービス)を記述する際に使用される用語である。しかし、それらの用語に対する共通的な定義は存在しないように見える。このことが、それらを使用する際に、混乱とあいまいさを引き起こす。それらの用語が何を意味するかに関しては、合意された定義がない一方で、粒度が「コンポーネント上のインターフェースが持つ操作の数」以上のものを意味する、ということに関しては、意見の一致があるようだ。Everware-CBDI(2005年6月版を参照のこと。登録後に参照可能。*2)は、「操作の数」以外の要素について、以下のように示唆している。(この記事では、単純化して紹介する。)

  • インターフェース上の操作を通じて呼び出される、DAG(directed-acyclic-graph)中のコンポーネント数 (C) *3
  • 個々のコンポーネントのファンクション・ポイント (F)
  • 生成、参照、更新、削除されるDBテーブル数 (D)

すると、粒度 (G) に対する1つの指標は、以下のとおりとなる。

G = C + F + D

単純にするために、コンポーネントは自己完結しており (C = 1)、1つのファンクション・ポイントを持ち(F = 1)、1つのデータベース・エントリを更新する(D = 1)とすると、粒度は3となる。このようなコンポーネントの例としては、直前の値に1を加えるための’increment’という操作のみを持つ、’Integer’クラスのようなものが該当するだろう。このようなコンポーネントはいくらでも再利用可能かもしれないが、アーキテクチャ的な(そしてビジネスの)観点からは特に有用なものではない。このようなコンポーネントは、実際の所”細かい粒度”と呼べるだろう。もう一つの極端な例としてのCRMシステムでは、おそらくC、F、そしてDのそれぞれが数千となり、粒度は幾万にもなるだろう。これもまた、アーキテクチャ的な観点からは、あまり有用であるとはいえない。それが非常に”荒い粒度”であるということを観察する以外に、あまりできることはないだろう。私たちアーキテクトは、おそらくこれらの極端な例の中間(この粒度の指標を使った場合、数百以下の領域のもの)のコンポーネントを作ること、そして(再)利用することに興味があるのだろうと、私は考える。

私たちがここで話したことは、ZapThinkが”機能的な粒度”と呼んでいるもの(”インターフェースの粒度”とは対照的なもの)である。つまり、コンポーネントが公開しているインターフェースの粒度というよりは、コンポーネント自体の粒度である。アーキテクトにとっては、この機能的な粒度を正しいものにすることが非常に重要なことである。コンポーネントの(機能的な)粒度が荒くなれば、ビジネス的なコンテキストでの有用性がより高くなるだろう。よって、部屋の予約に関するすべての面を扱い(つまり、日付、部屋の好み、ホテルの場所、顧客のロイヤリティなど)、適切な部屋を見つける”予約”コンポーネントは、アーキテクチャ的なレベル(つまり、私が最初に述べたような点)からも、ビジネス的なレベル(つまり、ビジネスの面から理解でき、そしてビジネス・ユーザーの要件にマッピングできる)からも、有用なコンポーネントである。

アーキテクチャ、そしてビジネスの文脈の両面において、最も有用となる正しい数のコンポーネントを持つためにも、システムをコンポーネントで構成する際に、どのレベルの粒度が必要となっているかを解くことが、システム・アーキテクチャを作るためのキーなのである。


(翻訳者のコメント)

コンポーネント・モデリングを初めて実践した際の大きな疑問の1つは、「1つのコンポーネントをどの粒度で作ったら良いんだろう?」でした。実は、今だに「これだ!」という答えを持てずにいます。

色々な人にコンポーネントの粒度について聞いてみたのですが、多いのが「着目している観点やレベルによって異なる」というものです。これは確かに正しいのですが、アーキテクトを長年経験しないと適切な粒度が判断できないのであれば、それは職人芸(暗黙知)であり、engineeringではありません。アーキテクティングを再現性のある方法論とするために、粒度というものに対して何らかの客観的な指標を持たせるという試行は、興味深いものだと思います。

*1:原文公開日:2011年4月15日。

*2:残念ながら見つかりませんでした…

*3:原文に当たれなかったので詳細は不明なのですが、対象となるコンポーネントが、直接/間接的に呼び出しているコンポーネントの依存関係をDAGで表した際の、コンポーネント数でしょうか…

コメントを残す

メールアドレスが公開されることはありません。 * が付いている欄は必須項目です