アーキテクチャ設計におけるモジュール化（１）
アーキテクチャはコンポーネントの構造として定義されます。この定義を見て、アーキテクチャはコンポーネントをモジュールにして実装すると思っている人が多いのではないだろうか？
しかし、ここで指摘したいのはアーキテクチャの設計、その構造定義と、モジュール化は分離して考えなければいけないことです。たとえば、Webアプリケーションやマイクロソフトのエンタープライズシステムでの参照アーキテクチャ、JavaEEで見られる多層モデルによるアーキテクチャの構造はモジュールではありません。
アーキテクチャのそれぞれの役割に応じて論理的なコンポーネントを定義し、それらが複合構造となっています。UI、UIプロセス、ビジネスロジック、データアクセス、データハンドラ、サービスエージェントなどと呼ばれる論理的なコンポーネントを構造化してアーキテクチャを定義します。このアーキテクチャに対して、保守の単位、品質の確保のための検証の単位、ユーザに対する有効な機能の単位、再利用の単位、などがどうなるかを考えてみましょう。これらが、モジュール化の対象となります。
現在のアーキテクチャはフレームワークは前提としますが、一回毎にカスタム（ワンオフ）開発する請負型の開発が大部分で、UI部品など物理的なコンポーネント、抽象クラス、UIスタイル、コーディングコンベンション、開発プロセスモデルなど、断片的、局所的な再利用に限定されています。つまり、モジュール化の対象として、再利用の単位、ユーザに対する有効な機能の単位を考えるほどの洗練されたレベルになっていません。このことは、アーキテクチャのコンポーネントの構造とモジュール化が分離できていない理由の1つでもある。また、現在の主流のオブジェクト指向が、再利用の単位やユーザに対する有効な機能の単位を分離するには、制約が大きいことももう１つの理由となっています。
たとえば、再利用の単位としてクラスを考える場合、単一責務の原則でクラスを定義したとしても、、非機能要求を含めるとクラスには多くの関心が含まれます。その結果、オブジェクト指向特有のもつれ合いの問題が発生します。このもつれ合いを回避し、再利用性を高めるには、クラスより小さい言語構造、あるいは、モデル要素が必要となるのです。Scala やC++にある”trait”という言語構造はこの問題を改善するために存在します。
ユーザに対する有効な機能の単位としては、Jacobson氏が提唱するユースケーススライスがあります。ユースケーススライスは、クラスだけでなく、既存クラスに挿入するメソッド、属性などをまとめて定義するパッケージです。これはユースケースがクラスに横断的になっており、やはりオブジェクト指向特有の散乱の問題を発生させるからである。
以上から、アーキテクチャの構造からモジュール化を分離できないのは、既存の技術制約が問題となっていることがわかります。
しかし、それ以上にワンオフ開発では、この技術課題を開発プロセスの改善などで補ってきた（*）ことで、本質的な問題の解決を避けてきたともいえます。再利用の問題1つにしても、あまり進んでいないのは、技術的制約にあるのではなく、ワンオフという開発の仕方が再利用を強制していないことによる面が大きいのです。
（*） クラスのリファクタリングで開発フェーズ、リビジョン、ビルドなどで調整する。