フレームワーク仕様とアプリケーション仕様の狭間に

フレームワークはカップリングを減らし、コンポーネントのメンテナンス性と品質の向上を考えるべきだと思う。
アプリケーションは疎結合なフレームワークを「結合」させて組み上げます。結合仕様がアプリケーションの骨組みになり、目的に合致したアプリケーションを組むならこの結合仕様を疎かにはできません。アプリケーションにとって重要な部分はアプリケーションの機能部分よりも結合仕様にあると思いますが、開発工数として認められるのは機能部分であることが多く、より重要な結合仕様がリサイクル品になっているケースを見かけます。
個人的には、フレームワークとは、さまざまなアプリケーション仕様を受け入れられるような抽象型と思っています。
人によってはフレームワークとは何かという時に、「速やかにアプリケーションを構築できるもの」というRADツール的意味あいで使うこともあります。そこでフレームワーク実装ではscaffoldが用意されますが、そうするとアプリケーションレイヤーに置くべき制約仕様がフレームワーク仕様の検討時に混入してしまい、逆にフレームワーク仕様を狭めてしまうリスクがあります。そのようなフレームワークでは、scaffold類似のアプリケーションの構築では高い効率とパフォーマンスを示すものの、別の仕様でアプリケーションを組もうとするときのストレスが大きくなる傾向があります。
確かに、あるフレームワークの特性を知るにはscaffoldは便利だし、単純なアプリケーションならscaffoldの微調整だけで済むから、カジュアルな開発者を集めるには効率的なのでフレームワークを広める第１材料としてはいいかもしれない。
しかし、フレームワークを必要としているサイレントマジョリティは、そんなことを必要とはしていないのではないか？という気がしなくもない。（何しろ、サイレントなので気持ちがわからない。）
設計者の立場で言えば、アプリケーション仕様は自前で作るから、土台だけ共有しようよ。っていう気持ちが暗黙のうちにあるような気がする。
〜〜はゲットーだというブログがあったが、そういう意味合いも少しはあるんではなかろうかと。
さて、本題に戻って、

たとえば、フレームワークの非制約例

あるフレームワークでは、コントローラーの命名規則や動作仕様がある程度決まっているが、それぞれのコントローラーの使い方については自由であって、各コントローラーやモジュール間の使用方法は制約が少なく、動作モデルとしては、ディスパッチループによってどのコントローラーも同じように呼び出されることを基本とする。デフォルトモジュールではモジュール名なしにコントローラー名を育成し、デフォルト以外のモジュールではモジュール名_コントローラー名という規則が決まっている。しかし、それらをどのように使うかは使う人の自由。その分、経験の浅い設計者だとそれらの自由仕様をどのように使ってよいかわからず、つかみどころがない状態になる。

アプリケーションの制約仕様の例

デフォルトモジュールのクラス名にはモジュール名を付けなくていいというフレームワーク仕様があるが、これを流用すると、デフォルトモジュールは、各モジュールへのディスパッチ専用コントローラーを実装することも可能だ。そして、そういう方式でディスパッチしますよという使い方をするという制約がアプリケーション制約となる。

フレームワークのメンテナンス性を考えるならアプリケーション制約レイヤーと非制約レイヤーをしっかりと分けられるようになっていることが望ましいと思う。もし、特定のアプリケーション仕様をデファクトにしてしまったら、ミニマムなアプリケーション開発者や、別の用途でデフォルトモジュールを使いたいユーザーには余計な仕様ということになり、それを回避するコードが必要になってしまう。
アプリケーション制約で実装するレイヤー、たとえば、モジュール用の初期化を自動的に処理するコンポーネントというのが当然になると、アプリケーションの構築手法について、主流と傍流が出来ることになる。ここに仕様の濃淡が生まれると、フレームワークの使い方とそのユーザー層やコンセンサスにも影響が出て、ゆくゆくは疎結合によるメンテナンス性の高さを捨てて、ワンパターンなアプリケーションファクトリーへと流れて行ってしまうのではないかと危惧してしまう。