n階層システム設計の考慮点

第1回 階層化アプリケーションとは

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

小規模~大規模のシステム構築を検討するにあたり,システムを階層化して構築することが多くなっています。人は,複雑なものをまとめて理解することはできません。そこで,階層化しそれぞれの階層に意味づけを行うことにより対象物を理解しようというわけです。そこで本連載では,今さらかもしれませんが,n階層アーキテクチャアプリケーションについて説明したいと思います。

n階層アーキテクチャアプリケーションのメリット・デメリット

n階層化アーキテクチャとは,アプリケーションを表示,業務処理,データ等,複数の階層で分割する分散アプリケーション設計手法のことを指します。

階層化にはどのような視点で分割するかによって,大きく「論理的役割」による分割と「物理的役割」による分割に分類できます。

論理的役割による分割とは,画面表示部,業務ロジック部,DB,ファイルなどのデータ格納部といった各階層の役割を意識して分割される場合です。

物理的役割による分割とはサーバマシンがハードウェア的に分かれることにより物理的に分かれてしまう場合と、同じサーバマシン内でも実行モジュールが階層化を意識して分割される場合があります。

以下に階層化分割のメリットとデメリットについて説明したいと思います。

論理的役割での階層化分割のメリット・デメリット

一般的に論理的な役割でアプリケーションを階層に分割した場合,以下のようなメリットがあります。

  • ソースコードのメンテナンスの容易さの向上
  • ソースコードの同一階層内での再利用性の向上による生産性の向上
  • ソースコードの可読性の向上
  • チーム開発時は並行開発ができるため,スケジュールの短縮を図れる

逆に以下のようなデメリットがあります。

  • 共通部品を各階層に再配置する必要がある
  • 論理的にソースコードが分られるため,ソースコードの絶対量は増加する

中小規模のプロジェクトでは,論理的に階層化しても物理的に1階層にすることが多いようです。

本方式では,業務に依存するロジックを特定の階層に押し込むため,仕様変更や機能追加に比較的強いと言われています。

ただし,一連のソースができて初めてテストが行える場合が多くなるため,特定の階層の開発が遅れるとスケジュール全体の遅れにつながる可能性があります。この点に注意して配分を検討する必要があります。

開発者にとっては,当人がアプリケーション全体のどの部分の開発を行っているのか分かりやすく,モチベーション向上が図れるようです。

物理的役割での階層化分割のメリット・デメリット

物理的な役割単位でアプリケーションを階層に分割した場合,以下のようなメリットがあります。

  • パフォーマンスの向上
  • スケーラビリティの向上
  • フォールトトレランスの向上
  • セキュリティの向上

逆に以下のようなデメリットがあります。

  • 各階層間のインターフェイスの複雑化
  • 業務としてのデータの流れや処理の流れが掴みにくくなる
  • 各階層の開発者は他階層の内容をインターフェイスしか判らなくなる→全階層を理解している開発者が少なくなる

大規模プロジェクトでは,論理的な階層分けを実施した上で,物理的にも階層分けすることが多いようです。

これらのメリット・デメリットをふまえて

ただ単にアプリケーションをn階層アーキテクチャにするのではなく,そのアプリケーションの規模や複雑さを考慮し,n階層アーキテクチャを検討する必要があります。

n層アーキテクチャの階層化以外に検討すること

前記しましたが,開発者が複数の組織,会社,国にわたる場合,技術的にコアな部分は自社(自部署)で開発し,その他の部分はほかに委託する場合など,開発環境に依存されることも多いです。

そのため,この規模・機能のアプリケーションだからこの方式がよいとは一概に言えないのが現状となっています。

しかし,開発者が複数人・複数個所にわたる場合,各種命名基準書やコーディング基準書などの整備や,基本設計書や詳細設計書の記載レベルを一定基準まであげ,ドキュメントを見るだけで開発が行えるようにする必要があります。

また,開発先との契約にも依りますが,納品前に静的解析を行い,コーディング基準に沿って開発されているか,単体テストおよび組み合わせテストを完了しているかなどをチェックできる資料を作成させることが必要です。

これを怠ると,最悪のケースとして納品されてきたが「設計書通りに開発させていない」,「開発者の国の言語で開発されているため,プロジェクトファイルが読み込めない」,「コンパイルエラーが発生する」,「テストがまったくされていない」等のトラブルの原因となります。これらを使用できる状態にするためには膨大な工数と時間が発生します。

Microsoft社が提唱するレイヤ型コンポーネントモデル

Microsoft社は以前から図1のような論理的役割で分割したレイヤ型コンポーネントモデルを推奨してきました。これも代表的なn階層アーキテクチャです。このモデルは現在も基本的に変わることなく,それぞれのコンポーネント内の技術やインターフェイスが変更,追加となり継承されています。

本モデルは簡単な構造をもつスタンドアロン型~大規模分散システムまでをカバーできるように汎用化されています。しかし,その汎用性のために,各コンポーネント内での基準,ルールの策定が非常に重要になっています。また,各コンポーネント間のインターフェイス設計も非常に重要になってきています。

図1 Microsoft社が提唱するレイヤ型コンポーネントモデル概念図

図1 Microsoft社が提唱するレイヤ型コンポーネントモデル概念図

次回は三層アーキテクチャモデルとそれぞれのレイヤに含まれるコンポーネントについて説明します。

著者プロフィール

露木敏博(つゆきとしひろ)

1966年神奈川県横浜市生まれ。1990年,株式会社日立システムアンドサービス(旧日立システムエンジニアリング株式会社)に入社。

流通系SE,営業所駐在SEなどを経て,2003年から生産技術部門で.NET技術に関する技術支援業務に携り,.NET技術に関する各種基準書および標準化,設計ガイドなどを作成。

マイクロソフトMVPアワードプログラムよりDevelopment Platforms - ASP/ASP.NETのカテゴリで2008年7月よりMVPアワードを受賞。

コメント

コメントの記入