Webアプリケーション設計に入門してきた

火曜日の続き。12月12日のPHPカンファレンスから。
「10年先を見据えて作るPHP　Webアプリケーション設計入門」を聴いてきたので
メモメモ

---

■10年先を見据えて作るPHP　Webアプリケーション設計入門
・今年はGMOグループで協賛
・１０年続くことってそうそうなくない？
　GMOだと
　　お名前.com(1999)、
　　まるごとserver
　お名前.comレンタルサーバー
　　BB.plus
　　GMOアプリクラウド
　　とくとくBB
　　このは
　　Z.com

・コードは変わっていく
　お名前。COMレンタルサーバー
　　SD
　　RD

・１０年の月日がもたらすもの
PHP
フレームワーク
　2003 phrameから
　直近１０年　Laravelない
　→フレームワーク変化激しすぎる

・フレームワークなどの特定技術から一定の距離を保つ必要がある
　→このサービス１０年続ける予定ないし
　　→よくできたプログラムは想定より広く長く使われる
　プログラムは分身する
　どうせ心血注ぐなら１０年続くと考えるほうが楽しい


・フレームワーク選定
　必要な機能を列挙する
　　ルーティング
　　すきゃフォールディング
　　ORM
　　IoCコンテナ
　　ミドルウェア

　チームの士気が上がるか、１０年後に残るかの観点で選ぶ
　→楽しくできるもの
　→１０年のこるから運しだい

　今回の題材はLalabel

・レイヤードアーキテクチャ
　アーキテクチャは重要→選ぶの難しい
　レイヤードアーキテクチャ
　上から下の依存OK,下から上はNG
　　ユーザーインターフェース　MVC
　　アプリケーション
　　Domain
　　インフラストラクチャ

・ディレクトリ構造とコードのながれ
　フレームワークへの宣戦布告：pakages
　コントローラ
　　アプリケーションを呼び出す
　アプリケーション
　　トランザクション：整合性が保たれる
　　ドメインのオブジェクトを操作
　ドメイン
　　インフラを呼び出す

・テスタビリティの確保
　　祈る→正しくない
　　祈りに熱中させないために
　　テスタビリティを確保する
　→DIP

・インフラストラクチャ層の取り扱い
　ORマッパーに依存：DBないと動かない
　何をどうやって
　　IoCコンテナ（DIコンテナ）→スタブを作る
　　→インターフェースによる抽象化
　DIP（依存関係逆転の原則）
　　上位レベルのモジュールは下位レベルのモジュールに依存しては
　　ならない。どちらのモジュールも抽象に依存すべきである
　　抽象は実装の詳細に依存してはならない
　　実装の詳細が抽象に依存すべきである
　→インターフェース使いましょうっていうこと
　主導権をビジネスロジックに
　プロダクションとデバッグで環境変えられる

・データモデルとドメインオブジェクト
　１０年たてば、インフラも変わる
　　政治的理由
　　インフラがドメインに依存すると、変えられない
　　だから分けとく
　アプリケーションドメインあざーずパターン（ADOPえーどっぷ）
　　アプリケーションとドメイン以外はすげ替え可能
　　ヘキサゴナルアーキテクチャとコンセプトは同じ

・セッション情報などの取り扱い
　OAuthが依存してしまう→インターフェースを切るでDI
　トランザクション→インターフェースを切る
　AOP

・バリデーション層はだれの役目
　枠の中は信頼する、枠の外は信頼しない
　：すげかえる必要があるから
　　UIのほうがバリデーション厳密

・エラー設計
　１０年とはあんまり関係ない話
　エラー設計こそが品質
　エラーは2種類　
　　システムエラー：サーバーダウン　５００系エラー
　　ユーザーエラー：入力変えればOK　４００系エラー
　ユーザーエラーでは例外を発生させない
　　→コントローラーでtry-catchを使わない

・横断的関心事（おうだんてきかんしんごと）
　必要な機能
　　ミドルウェア
　　　ミドルウェアでnot found(404)
　　　→例外

・まとめ
　ADOP：１０年戦える
　　　UI　　インフラ
　　　アプリケーション
　　　ドメイン

　初期段階：そんな作りしていない
　実際にはこんなに立派に作らなくても１０年続く？
　なるべく血も汗も涙も流さない
　→１０年先を見据えて作る

・おまけ
　大事なもの
　　セキュリティ:徳丸先生見ましょう
　認証：自作は最後の手段。フレームワークを使いましょう
　　ユーザー情報、認証がすでに自前で用意されている
　　→ライブラリに乗っかる
　そのほか注意：安全なウェブサイトの作り方を見ましょう

　2020年今年のPHP漢