Symfony Advent Calendar 2020 24日目の記事です！
カルテット開発部では基本的にWebアプリケーションはSymfonyを使って開発していますが、実は「フレームワークはどうでもいい」と考えています。
「え？どういうこと？」という反応が予想されるので、内容と理由について説明します。
「フレームワークはどうでもいい」
私達が作りたいのは我々のモデリングしたドメイン（リスティング広告運用業務のドメイン）を体現したアプリケーションです。フレームワークのイケてる機能を使ったアプリケーションではありません。
モデリングしたドメインを適切に表現してユーザーに提供できるなら、フレームワークもプラットフォームも何でも良いのです。究極的にはエクセルマクロでも良いぐらいです。
現時点では「Webアプリケーションという形式に乗せたい」という要求があるため、WebアプリケーションのプラットフォームであるPHPを利用していて、WebアプリケーションのフレームワークであるSymfonyを選択しています。
Lisketも最初は社内向けのエクセルマクロから始まっていました。Webアプリケーションにすることで、社内の担当者間・チーム間での情報共有や引き継ぎがスムーズになります。SaaSとして社内のみならず社外にも価値を届けることができます。
なお、コロナウィルス感染症対策のためにカルテットの営業・運用部門でもリモートワークが実施された際、必然的に多拠点対応が必要になりましたが、Webアプリケーションになっていたことで担当者のマシンスペックやOSに左右されずに各種効率化ツールを提供し続けることができました。
フレームワーク選定基準
次に、PHPのWebアプリケーションフレームワークが多数ある中で、特にSymfonyを選んだ理由について。
最初に選んだから惰性で使い続けているわけではありません。日本Symfonyユーザー会のメンバーが在籍しているからSymfonyを使っているわけでもありません。
全面刷新するリニューアルのタイミングでもSymfonyを選び続けているのです。
- 認証やセキュリティ・ルーティング、HTTPのリクエストを受け取ってレスポンスを返すのが面倒じゃない
- 私達がモデリングしたピュアPHPによるドメインのコードを邪魔しないこと
- 今のメンバーだけでなく将来に渡って、ピュアPHPによるドメインのコードを邪魔しない思考法を誘導してくれる
の3点を満たすPHPフレームワークがSymfony以外に見当たらないという理由です。
1つ目は、普通のWebアプリケーションフレームワークなら大抵は満たしますね。少なくともこの部分にバグがあったり、頭を使って工夫しないと実現できないようだと採用するのは難しいです。
2つ目は、クラスの命名規則やファイルの配置について、フレームワークからの強制がないかどうか、という点です。Webアプリケーションの構造の中にドメインのコードを埋め込みたいので、フレームワークの規約に合わせるためにドメインのコードの側を変えることを求められるようだとNGです。
Symfonyはautoloadしたものはほぼautowireできるうえに、Resolverに大量の同種interfaceをaddしたいときにもフレームワークのDIコンテナが（邪魔するのではなく）助けてくれます。
※どのように助けてくれるのか？は過去記事をご参照ください。 Symfonyで同種のクラスを大量に使うときDIで楽するテクニック（自作タグのススメ）
3つ目については、先日小さな勉強会でLaravelについて私が発表した こちら がちょうど反面教師となっています。
Laravelの提供する便利なresolve関数があることで、やろうと思えば resolve(Hoge::class) のようなコードをドメインのコード内に書いて、ドメインからフレームワークへの逆方向の依存を発生させることができてしまいます。ベテランばかりの今のメンバー構成だと良いのですが、今後新人さんが入ってきたときには、わざわざ「resolveを使わない」のようなローカルルールを覚えてもらわなければなりません。その点Symfonyでは、DependencyInjectionパターンの利用を原則として強制されるので安心です。
なお、Symfonyでも厳密に言えば ContainerAwareInterface を使ってドメインのコードにコンテナをinjectすることは可能です。が、普通に初心者向けドキュメントを読みながら開発してもたどり着かない方法なので、新人さんをいきなりタスクにアサインしたとしても不意に使われる心配はほぼありません。