アーキテクチャ設計とは：MSDNブロガーの視点

MSDNブロガー 萩原正義氏がシステムアーキテクチャの基礎を解説します。初出は2007年4月。歯ごたえのある技術論です。

[萩原正義（マイクロソフト），ITmedia]

（このコンテンツはMSDN Blog「The First Virtue」からの転載です。エントリーはこちら。なお、記事内容はすべて筆者の個人的な見解であり、筆者が勤務する企業の立場、戦略、意見等を代表するものではありません）

　レイヤーアーキテクチャを語るための事前準備。

　レイヤーという言葉は開発ライフサイクル管理の中では複数の箇所に登場します。

　概念レベルの分析段階で使われるレイヤーは、概念モデルの分類、責務の配置に関して使われます。したがって、分類法の一種です。一方、レイヤーアーキテクチャは、非機能要求を論理的なノード上の配置で動作させるための実現法です。ここで、論理ノードとは必ずしも物理ノードを意味しないで、ノード上のシステムのバージョンや構成定義の条件を決めます。

　概念モデルは分析を経て責務がそのモデル上に配置されます。次に概念モデルを適切な分割単位であるパッケージやコンポーネント上で動作させます。このパッケージやコンポーネントの構造がアーキテクチャです。レイヤーアーキテクチャのレイヤーはここでのパッケージの一種です。概念モデルの責務は、適切な基準の下で、パッケージやコンポーネント上に配置されます。この場合、責務を純粋に動作させるのはコンポーネントの方です。

　この関係を分かりやすく示すと、

　概念モデル→パッケージ（レイヤー）⊃コンポーネント⊃クラス。

　パッケージはそれでは何のためにあるのでしょうか？

　パッケージは多くの場合、モジュールと言い換えてもいいです。その役割は、本質的には、変化の単位を示します。つまり、なんらかの理由でソフトウェアを変更しなければならない場合、同時に変更を行わないとつじつまが合わない範囲を示します。同時更新の単位は、多くの場合、配布の単位やバージョン管理の単位になるので、モジュールの形で実現されます。もっとも、パッケージは論理レベルのモデルですが、モジュールはそれを物理レベルで実現しているモデル（主にファイル）です。ですから、概念モデルの責務はコンポーネントに配置され、コンポーネントの変更の単位をパッケージが支えるという関係です。変更の単位は、適切に依存関係が整理されていないといけないので、コンポーネントを構成するクラスの依存関係からボトムアップに整理して決められるのが現実的と思えます。しかし、プラクティスとして存在する、参照アーキテクチャでは、データはUIより変更頻度が少ないという経験に基づいて、データやUIをレイヤーとしておおまかなパッケージのくくりを用意しています。この程度のおおまかなくくりであれば、ボトムアップの依存性分析をしなくても大体正しいということが言えるからです。

　アーキテクチャは一般には非機能要求を実現するので、概念モデルを動作させる枠をパッケージやコンポーネントで提供しているといえます。しかし最近では、ビジネスアーキテクチャがソフトウェアを動作させる色彩が強くなっているので、ビジネスアーキテクチャが決める概念モデルがシステムアーキテクチャのパッケージやコンポーネントの枠を決めると考えることもできます。

　非機能要求だけではないのです、システムアーキテクチャを決めるのは。

　そうした発想は、Zachmanフレームワークでのビジネスのビューがアーキテクチャとしてとらえられている点や、ドメインドリブン設計から読み取ることができます。

　コンポーネントに責務が配置されると、そのコンポーネントの持つべきインタフェース定義を決めることができます。もちろん、責務とインタフェース定義は双方で調整がされて、決定されます。責務を動作させる、最適な構造は何かという観点で。

　ここで、インタフェース定義は古典的には、事前事後条件や入出力で定義されるのですが、最近では、これにセキュリティやネットワーク呼び出しの有無、同期／非同期などの条件が加わります。これらは物理レベルの話ではなく、論理レベルの話であるので誤解なく。

　こうして、アーキテクチャ設計が決定されます。