拡散する問題と収斂する問題
イギリスの経済学者エルンスト・フリードリッヒ・シューマッハーによればこの世界には二種類の問題があります。(1)
- 拡散する問題（divergent problems）
- 収斂する問題（convergent problems）
例えば「新しくWebアプリケーションを作成する」事を考えてみましょう。もしそれまでにPHPを使用した事がなかったとしたら、どういう選択肢があるかあらゆるオプションをリサーチする必要があります。
フレームワークを使用するのか？そうならフルスタックか？マイクロフレームワークか？それらはどのような背景で設計され、どのようなコミュニティで運営されているのか？対象とするアプリケーションは？開発者は？パッケージは？エコシステムは？メンテナンスコストは？
そもそもPHPは必要なのでしょうか。JSフレームワークでSPA(single-page application)はどうでしょうか？
...これらは「拡散する問題」です。Webアプリケーションという１つの目的地にたどり着くため、選択可能なオプションを検討し問題は拡散していきます。
そしてある時点でマインドセット（思考態度）を変え、つまり問題を拡散から収斂のほうに変え、指針や指向を元に選択肢を減らし１つの解決策に導きます。拡散する問題は基本的に論理的な解決がなかなかできません。しかし設計指針（アーキテクチャ）という志向を与えることで問題を減らしていくことができます。
設計に必要なプロセス
これはシステムの設計に必要なプロセスだと考えます。（アプリケーションアーキテクト不在のシステムではこのプロセスは省略されます。ベストプラクティスのテンプレートを適用するだけのようなシステムはそうです。あるいは「今流行しているフレームワークはなんですか？」という問いはどうでしょうか。デファクトスタンダードの不在を嘆くということはどういうことでしょうか。）
BEAR 0.x to 1.x
BEAR.Sunday0.xの版を重ねる度に問題を拡散し可能性を探ってきました。
- Webエディタ
- リソースのメタデータを表示する”ハロー”
- リソースのリフレクション（一覧）
- オブジェクトグラフビジュアライゼーション
- Smarty / Twig テンプレートエンジン
- AOPによるフォームの問題の解決
- @Cache @CacheUpdateによる"なんちゃってCQRS"
- シグナルパラメータ
- ベストプラクティス
- ランタイムコンテキストによる(AOPによる）DI
- DIによるAOP（ルーターコレクションなど）
なかなか解決できない問題もありました。
- アプリケーションコンテキスト
- DIコンパイラ
- AOPインターセプター
他にもいろいろあります。十分なフィードバックが得られたものもありますし、そうでないものもあります。
コンバージェンス（収斂）としての1.0
そして、フィードバックや、いくつかのプロダクションを出荷して確信をもてたものに収斂するときが来ました。マインドセットを変えたのです。
きっかけは、なかなか改良の延長で解決できなかったRay.Diをv2.0としてOOPで完全に書き直したこと、phpnwの二度目の参加、その時のリチャードさんとのディスカッションなどです。他にも背景として、グラハムさんの余計なものを取り込むべきでないとのアドバイス、ネーテさんにインスパイアされたと言われたこと、QiitaやブログでのBEAR.Sundayの記事、Auraフレームワークの進化、これまでのissue..など様々な事もあります。
- アプリケーション制約としてのフレームワーク
- 接続フレームワークであること
- クリーンでコンパクトであること
- アプリケーションロジックをアスペクトとして実装するこ と
- アプリケーションの拡張ポイント
- ハイパーメディア(REST)
- DIをアプリケーション構成に使うとと
- アプリケーションアーキテクトに良い制約を提供すること
これらのコアバリューだけに集中して、品質が高く、将来変更可能性のほとんどないものだけに取り組み1.0としてリリースすることを考えました。
＊以前の久保さんとフレームワーク拡張についてのディスカッションを再考し、これも"コンバージェンス"しました。
フレームワーク構成
https://github.com/koriym/BEAR.Sunday/tree/develop-2/src/Extension
まとめ
1.0では0.xであった様々な付加的機能が集約されたり、一旦外されたりしています。例えば今現在はHTML出力やDBはオプション扱いでデフォルトのテンプレートエンジンやDB(ORM)ライブラリは付属しません。デバック出力のハローやHTMLエディタなどのデバック機能も一旦外していて付属しません。(HTMLを利用しない開発者には不要です）✴︎時間や労力をかけて苦労して作ったライブラリもほとんどの部分を外しています。
現在デフォルトではWebルーター（オプションでAuraルーター）によるルーティング、JSON(オプションでHAL)出力が可能なAPIサーバーとして機能するものが提供されるのみです。
これではフレームワークと言えないと思われる方が想像できる一方で、これで十分だと思われる方がいることにも確信があります。アプリケーションやフレームワークの構成変更可能性は高く、アプリケーションアーキテクトの構成設計要求に応えれるものができているのではと考えています。
最後に1.0リリースで最も気を付けている事を紹介して、この記事を終わりにします。
プラクティスではなくプリンシプル（原則）にフォーカスすること