回避策を考えるより、書き換えた方がクリーン。だからフレームワーク
オープンソースのＣＭＳやフレームワークもいろいろあるけれど、それを業務ニーズにマッチさせようとすると何かと拡張が必要になる。
CMSの変更は黒魔術的
その時、それらのシステムが用意した拡張ポイント、プラグインやらコンポーネントやらで回避的に目的の挙動を作りだすことはできるけれど、本体をいじらないという前提を持ってしまうと、拡張は黒魔術的になる。
製品としてリリースされるCMSの場合、システムの深層での拡張ポイントは普通は存在しない。(高度な拡張性を自然に用意しているものもある。）拡張の余地を残さずにハードコーディングしていった方が二つの意味-開発スピード・パフォーマンス-で有利だから。（開発スピードというよりも高度の抽象化が必要ないというべきだが）結果、CMSの場合は拡張時に直接システムの書き換えが必要になる。変更点が拡大しリリースの度に変更点を追わなければならないので保守コストが増す。そこで、コアコードと分離したプラグインやモジュールで回避するのが常套手段になる。
フレームワークは拡張で実装する、拡張ありき
しかし、フレームワークと名のつくものであれば、フレームワークソースを直接変更することなく（パッチワークせずに）システムを構成するクラスを追加・もしくは換装する。アプリケーション構造としてフレームワークを使いつつ、完全に自前のシステムニーズにマッチしたものになる。ミニマムなやっつけ仕事でないかぎり、フレームワークベースでカスタム開発する。そんなスタイルが好きだ。
そういう意味でフレームワークには、簡素な枠組みと豊富なコンポーネントを期待したい。あとはそのうえで動作するフレームワークを自分で構成できる。そして、土台となるフレームワークの拡張性を引き継げるので、その上で動作するフレームワークも同様に拡張可能になる。
