12月12日（土⁠）⁠，PHPカンファレンス2020が開催されました。 PHPカンファレンスは今年20周年の節目を迎え，初のオンライン開催となりました。 本稿ではその模様をお伝えしていきます。前編では2つのセッションを取り上げます。

成瀬允宣さん「PHP WEBアプリケーション設計入門 —⁠—10年先を見据えて作る」

GMOインターネットの成瀬允宣さんは，10年続くサービスを開発するために必要な考え方や知識，具体的な実装テクニックやプラクティスなどについて話しました。

10年続くサービスと，PHPやフレームワークの移り変わり

10年という言葉にどのようなイメージを持つでしょうか？ 10年続くサービスはそれほど存在しないのではないかというイメージがあるかもしれません。しかし，GMOインターネットではお名前.comやまるごとサーバー，お名前.comレンタルサーバー，GMOアプリクラウド，ConoHa byGMOなど10年続いているサービスはたくさん存在します。成瀬さんは「これほど多くのサービスが存在していれば現実味を感じてもらえるはず」と述べていました。

しかし，10年前に書かれたコードが今現在も同じということはなく，存在し続ける以上確実に変わってきているそうです。この10年で変わったことはコードはもちろんのこと，フレームワークやデータベースなどの特定の技術も挙げられると語りました。

そしてPHPの歴史はPHP toolsから始まり，25年の月日を経て，最近ではPHP8.0がリリースされています。フレームワークについてはphrameというものが最初に現れました。その後，様々な激しい変化を経てCakePHPやFuelPHP，Laravelなど多くの方が知っているフレームワークが登場してきます。

また，10年も続ける予定はないと思いながら開発を進めるサービスでも，よくできたそのプログラムは他の開発者に参考にされることがあります。そのようにプログラムは分身を続け，いつだって当初の想定よりも広く長く使われることがあるのです。成瀬さんは「心血を注ぐなら10年動くことを信じたほうが楽しい」と述べていました。

フレームワークの選定と，設計する際のアーキテクチャ

フレームワークを選定する際にまずすべきことは，ルーティングやORM，スキャフォールディングなど，必要な機能をまず列挙することです。そして，それらの条件を満たすフレームワークを候補として，その中でチームの士気が上がるかどうか，10年後に残っているかどうかということを考えながら選定します。10年後もそのフレームワークが存在するかは運次第ですので，むしろ10年後に残らないものとし，特定の技術スタックから乗り換えを前提にします。総じて言えることとして，フレームワークから一定の距離を保つことが大切だと指摘します。

アーキテクチャは重要な要素ですが，アーキテクチャ自体がそもそもよくわからなかったり，どれが最適であるかを選ぶのが難しいといった声があがります。そこでお勧めするのがレイヤードアーキテクチャです。レイヤードアーキテクチャは上から順に，User Interface（MVC⁠フレームワーク）⁠，Application（ドメインオブジェクトなどを利用するコード⁠）⁠，Domain（ビジネスルール⁠）⁠，Infrastructure（DBなど）の4階層に分けられ，上位層から下位層への依存は許されますが，下位層から上位層の依存は許されません。

テスタビリティの確保

次にテストの話に移りました。「⁠テストできない時に開発者にできることはなんでしょうか？」と問いかけ，なにもしない期間を祈りながら過ごすよりも，自分の書いたコードを自信を持って正しいと言えるために，テストをできるようになっていること，つまり，テスタビリティの確保が重要であると話しました。

そのために必要な知識がDIP（Dependency Inversion Principle；依存関係逆転の原則）です。DIPは，上位レベルのモジュールは下位レベルのモジュールに依存してはならず，また，どちらのモジュールも抽象に依存するべきで，抽象が実装の詳細に依存してはならないというものです。

たとえば，ORMに依存するコードを書いてしまうと，テストがしづらいなどの問題点があります。それを解決するには，インターフェースとIoC Containerを利用して，モジュールを切り替えられるようにすることが良い方法です。そうすることで，初期開発や新規機能開発にありがちな，モデリングやコーディングをしていたらデータが違ったためテーブル定義から変更せざるを得ないことになるような場合でも，スタブを使っていればパラメータを書き換えるだけで済むようになるからです。これによりプロダクションとデバッグの環境を分けられるため，開発がしやすくなります。

データモデルとドメインオブジェクト

10年経てばインフラも変わります。たとえばデータベースが変わることがあります。よって，Infrastructureに依存してしまうと気軽に挿げ替えができなくなります。そのため，Infrastnructure層とDomain層を分けておく必要があります。ただここで，レイヤードアーキテクチャにしたがうと，Application層やDomain層からInfrastructure層への依存が肯定されてしまうと言及しました。

そこでApplication Domain Others Patternというアーキテクチャを成瀬さんは提案しました。このアーキテクチャではUser Interface層とInfrastructure層を挿げ替え可能にし，Application層とDomain層を10年後も使えるようにしたことを説明しました。

エラー設計について

10年とはあまり関係のない話としつつ言及されたのが，エラー設計の話です。成瀬さんは，エラー設計こそがサービスの質だと考えられると言います。

エラーには2種類あって，システムエラーと呼ばれるデータベースが落ちるなどのようなユーザーに伝えても意味のないものと，ユーザーエラーと呼ばれるIDの重複など情報（価値）をユーザーに伝えるべきものがあります。サービス内で起こったエラーをコントローラ内でtry-catchなどを使わず，ユーザーに伝えるべきものは伝え，伝えなくてもよいものはこちらで処理を進めるなどの動作をコードに落とし込むことが大切だとしました。

まとめ

最後に成瀬さんは，「⁠⁠実際にはこれほど立派に作らなくてもサービスが10年続くことはあると思います。しかし，そのサービスが継続できたのは，誰かの血と汗と涙の結晶であることもあるのです。なるべく血と汗と涙を流さないために10年先を見据えて設計をしましょう」と述べ，発表を締めくくりました。