アーキテクチャとはなんであろう。

かの有名な ぼそっと にて色々と興味深い見解を述べられていたのでノッてみる。
（chiba_さんごめんなさい）


http://d.hatena.ne.jp/chiba_mk3/20080714/1216050596
http://d.hatena.ne.jp/chiba_mk3/20080715/1216135665

まず、俺が思うアーキテクチャ

アーキテクチャとは、構造である。

構成じゃなくて構造だと思います。少なくともITアーキテクチャについては。言葉遊びですけど。
この言葉って「構造化プログラミング」から来てると思うんですよね。

構造化プログラミングは、順次・分岐・繰り返しのみでプログラムするってのがポイントですが、それに加えて、システムを機能単位で分割して組み合わせる、という意味もあります。
サブルーチンの概念ですね。
この「機能単位で分割されたものを組み合わせる」という概念はOOPでもAOPでも変わりません。つまり、現在作られてるシステムはほぼ全て「構造化された」システムである、と言えると思います。

よって俺は、

構造化されたシステムの構造のことを、我々はアーキテクチャと呼んでいる。

と考えます。

つまり、コンポーネントだったりサブルーチンだったりはたまたクラスだったりの組み合わせ方。がシステムのアーキテクチャである。

と私は考えます。

さて、ここまでを踏まえて、俺が違和感を感じたところはここです。

やっぱり、そもそもの言葉の意味的に考えると、「アプリケーション・アーキテクチャの確定＝各問題領域毎のフレームワーク・コンポーネントを組み合わせて要件に適したフルスタックフレームワークを構築すること」と考えても差し支え無いような気がしてきました。

フレームワークを構築することは、アーキテクチャを確定させることの一部でしかないと思うんです。俺は。
確かにフレームワークを確定させれば、システムの大枠は決まります。
でもフレームワークが担うのはあくまで汎用的な機能だったり処理パターンであって、システム独自の機能というのは別途開発しなくてはならないはずです。
その独自の機能のところの構造まで確定させて初めて、アーキテクチャの確定と言えると思います。
全部作れ。と言ってるわけではないです。
インターフェースで下位のクラスの挙動を束縛したり、UML等で概要だけ決めたり、代表的なところだけ作って後はそれを模倣させたり、と構造を確定させる手段は色々とあると思います。
ここまでやらないといけないから、アーキテクトって大変なんですね。多分。


と、俺の理想とするアーキテクト像を元に、言いたいこと言ってみました。

若干後悔していますが、異論もお叱りも認めます。ごめんなさい。