Comparators―比べてみればわかること

第4回 Layered vs.Connected

この記事を読むのに必要な時間:およそ 3 分

あるとき休憩室で,私は同僚にたずねました。⁠分散ファイルシステムに載った分散データベースにクローラがインデックスを保存,インデックスの隣にはキャッシュサーバが並んでいる。そんな検索エンジンのシステムを図に描くとどうなりそう? チームの新入りにレクチャーする感じで教えてよ」

部屋の壁にかけられたホワイトボードに向かい,同僚は箱を積み上げる図を描きました図1左側)⁠同じ質問を受けた別の同僚は,丸を矢印でつないだ図を描きました(図1右側)⁠

図1 LayeredとConnected

図1 LayeredとConnected

どちらの図も現実の検索エンジンを反映したものではありません

同僚4人に質問を続けたところ,結果は2対2の引き分け。決着をつけようと声をかけた5人目には「それは……,場合によるよ」と言葉を濁されてしまいました。

箱を積み上げた1つ目の図を,ここではLayeredと呼ぶことにしましょう。丸を矢印でつないだ2つ目の図は,Connectedと呼びましょう。検索エンジンのシステムとして正しい図は,LayeredConnectedのどちらでしょうか。

ビューとスタイル

正解は言葉を濁した5人目。望ましい図の描き方は「場合による」のです。文書化用語では,システムの概観をとらえる図1のような図をビューArchitectural Viewsと呼びます。図は関係が薄いものを省き,説明が伝わるよう要所要所を強調します。同じソフトウェアに対して,ビューはいくつも存在します。伝えたい相手や目的によって,必要となるビューが異なるからです。

カレーライスの例で考えてみましょう。

神保町でカレー屋に入りました。メニューを開けば,チキンキーマカレーの盛り付け,辛さ,値段がわかります。メニューはカレーに対するビューの一つです。顧客の食事選びを助ける役割があります。

もう一つのビューは厨房のレシピです。肉,野菜,調味料の分量,調理手順や味付けがわかります。料理人の調理を助ける役割を持つビューだと言えます。

メニューやレシピにはさまざまな見せ方があります。見せ方によるビューの分類をスタイルと呼びます。LayeredやConnectedもスタイルの一種です。書籍『ソフトウェアアーキテクチャドキュメント』注1には,広く利用されているビューのスタイルが紹介されています。LayeredスタイルとConnectedスタイルは,よく見かけるスタイルの代表格です。

注1)
Paul Clementsほか著/前田卓雄訳『ソフトウェアアーキテクチャドキュメント ─⁠─ ソフトウェア戦略の中核:アーキテクチャを捉えプロジェクトを革新する』日刊工業新聞社,2004年。

静的な構造を扱うLayered

Layeredスタイルはソフトウェアの静的な構造を描くのに向いています。ソースコードに現れるような構造,たとえばクラスやパッケージ,名前空間などが静的な構造です。

Layeredスタイルでは,積み上げた箱をモジュールと呼びます。モジュールは,クラスやパッケージといった何らかの論理単位です。Layeredスタイルでは,上に積まれたモジュールが下側に依存する一方向の依存だけを持ちます。

動的な構造を扱うConnected

Connectedスタイルはソフトウェアの動的な構造を表すのが得意です。実行時,デプロイ後に見られるプロセスやサーバ同士の関係が動的な構造です。プロセスやサーバはコンポーネントと呼ばれます。Connectedスタイルではコンポーネントを円で表し,メッセージを表す矢印で円同士をつなぎます。矢印の種類を描き分ければメッセージの種類を区別できます。

お気に入りのスタイル

静的な構造にLayered,動的な構造はConnected。どちらを選ぶかは目的次第です。冒頭の雑談中,Layeredスタイルのビューを描いた同僚はコード上での静的な構造を,Connectedスタイルのビューを描いた同僚は実行時の動的な構造を伝えたかった。そう考えることができます。

けれど,日々の議論で私たちはそんな風に図を使い分けているでしょうか。いつも同じビューばかり描いていませんか。筆者の観察によれば,使われるスタイルは仕事の分野による偏りがあります。

クライアントサイドに中心を置く組込みシステムモバイルアプリの世界では,Layeredスタイルに人気があるようです。⁠Android Architecture」⁠Qt Architecture」などと検索すれば,Layeredスタイルで描かれたビューをいくつも見つけることができます。

分散システムを伴うWebの世界ではConnectedスタイルが優勢です。High Scalabilityに代表されるWebアプリケーションのアーキテクチャ解説サイトは,いつもConnectedスタイルのビューで賑わっています。

こうした偏りには事情もあります。クライアント主体のシステムは,プログラムの大部分がプロセスやマシン境界をまたがずに動きます。代わりにプログラム一つ一つが大きく複雑で,静的な理解の出番が多くなります。

一方,Webのシステムは個々のコンポーネントが比較的単純。代わりに複数のコンポーネントがプロセスをまたいで動作します。デプロイ後のトラブルシュートにも多くの時間を費やすこうしたシステムでは,実行時の関係を注視するConnectedスタイルが当てになります。

スタイルの支配

このように,スタイル選びはシステムの性質を反映します。とはいえ1つのスタイルに慣れ過ぎるのも危険です。説明の道具にすぎないビューのスタイルが,デザインに滲み出してしまうからです。

Connectedスタイルの支配するチームで,あるとき新しいプロジェクトが始まりました。プロジェクト序盤のある日,あなたはミーティングに出席します。プロジェクトに参加する開発チームが集まり,担当の割り当てを議論するためです。ホワイトボードには想定されるシステムのビューがConnectedスタイルで描かれています。クライアント,フロントエンドサーバが1つずつ,バックエンドが複数,そしてモニタリング用ノードです図2)⁠

図2 とあるシステム

図2 とあるシステム

会議は紛糾します。どのチームもフロントエンドサーバを開発したがらないのです。アプリケーションロジックの多くを担うフロントエンドサーバは,開発規模が大きい貧乏くじ。下手に引き受けるとデスマーチが待っています。長い押し付け合いの末にデザインの折衷案が現れました。

著者プロフィール

森田創(もりたはじめ)

平日はWebブラウザの開発,休日はWebブラウザの利用に従事。最近の趣味は/etc/hostsファイルに中毒性の高いWebサイトをリストし,127.0.0.1にリダイレクトすること。現在7サイト。スマートフォンの勉強をしなければと思いつつ/etc/hostsにアクセスできない端末を持つのが不安で躊躇している。

http://steps.dodgson.org/

コメント

コメントの記入