PHPFUK15
今年は6/27に行われた記念すべき第一回PHPカンファレンス福岡で基調講演をする機会をいただきました。去年の大阪に引き続いてタイトルは同じ「全てを結ぶ力」でしたが基調講演に続いてYOUR.Sunday というタイトルでもセッションを行いました。
その中で「解法ではなく問題を」という問いかけを行い、一つの仮定をしてみました。PHPのフレームワークは数はたくさんあるが、Webの問題の捉え方は同じで問題解決の構造は本質的にどれも変わらない。解法には方言や方針があるが重要なのは問題をどう見るかではないかというものです。
(どのフレームワークか分かりますか？）
構造を
フレームワークの本来の価値は利便性より問題解決の構造にあると考えば、新しいアイデアに基づいた新しいフレームワークの存在価値があります。
BEAR.Sundayは「RESTfulなアプリケーションは内部もRESTfulにすれば良いのでは？」というな考えが設計のベースになっていていますが、他にAuraのADRパターンやCQRSをベースにしたlitecqrs-phpというフレームワークを紹介しました。これらはWebの問題を従来とは別の捉え方で捉えたものです。PSR７ミドルウエアフレームワークもHTTPメッセージを軸にして問題を捉えています。
YOUR.Sunday
Slimに似たマイクロフレームワークを新たに作成する意味は薄いですが、既存の「コントローラーが"モデル"からデータを受け取ってテンプレートで表示する"MVC"」ではないもの、新しいアイデアに基づいたものや、ドメインに応じたフレームワークを作ることには意味があります。
早く簡単に記述できる利便性は確かに価値の１つですが、自分のドメインの価値は何かを改めて問い、Webの問題をよりよく解決することにも意味があります。
現在のcomposer / Packagistのコンポーネントはそれを後押しします。ルーターやテンプレートエンジン、DIやORMを自作する必要はありません。本来はそれらは独立したコンポーネントとして存在できるもので、密結合したフレームワークの専用品として存在しなくてもいいものです。
BEAR.Sundayのようにフレームワークを作ることもできます。それがセッションのタイトルの"YOUR.Sunday"です。一方、BEAR.Sundayを自らのドメインフレームワークのベースとして使うことができます。使用するコンポーネントをDIで束縛して、アプリケーションのユースケースをAOPで記述します。HTML WebアプリケーションからSPAに移行することがあってもコンテキストだけを変更して、アプリケーションはほぼそのまま使用することができます。
BEAR.Sundayにはその柔軟性と力があります。