フルスタック
GitHub, Composer, Packagist ... これだけ疎結合の良質なコンポーネントが選択可能でFIGなどのインターオペラビリティ（相互運用）が整って来ている時代に全てを提供する「フルスタックフレームワーク」の価値は何にあるのか、本質的なものが問われる時代が来るのではと考えています。
設定より規約でオブジェクト間の関係もハードコードしてある密結合のシステムではフルスタックは必須で機能します。「早く簡単に」つくれる事は素晴らしいことで価値があります。しかし一般にこれらはRAD（早期プロトタイピング）のためのフレームワークです。本来は短期的な問題をうまく解決するようにつくられたアーキテクチャです。
しかし例えば、60/60ルールのように変更可能性や保守性をより重視することを考えたらどうでしょうか。疎結合で相互運用性が高いシステムにとって、フルスタックの意味はどのようなものになっていくでしょうか。
アプリケーション制約
アプリケーション制約としてのフルスタックはどうでしょうか。アプリケーションが使用するコンポーネント一式をオールインワンパッケージとして提供してやり、それらをセットで使ってもらうことでアプリケーションに制約が生まれます。
ノースタック
BEAR.Sundayはこのようにオールインワンのライブラリを提供することでアプリケーション制約を提供していません。
変わりにオブジェクト間の関係や横断的関心にDIPやAODといった制約を設けています。情報を単なる値として取り扱うのではなく、リソースとしてハイパーメディア制約を設けています。
制約 as a power
ソフトウエアに真の力を与えるのは適切な制約だと考えます。PHPの言語としての進化もそうです。PHP4ではpublicしかなかったメソッドの修飾子にprivateとprotectedが加わりました。スタティックメソッドは嫌われ、どこからでもアクセスできるグローバルなシングルトンも多くのフレームワークでは利用できなりました。
何か出来なったものが出来るようになってる訳ではないのです。できなくなっているのです。しかしそれらは適切な制約として機能し、短期的な問題より長期的な問題により良く対処します。
アプリケーション制約をフレームワークとして考えると、フレームワーク設計というのはアプリケーション制約の設計に他ならないと考えます。