フレームワークとの付き合い方 / how-to-use-framework

2019/02/16 Laravel JP Conference

Transcript

1. フレームワークとの付き合い方 2019/02/16 Laravel JP Conference @shin1x1
2. なぜフレームワークを使うのか？ 2
3. 楽をするため 3
4. 楽をするために全力を尽くす [ 全体の労力を減らすために手間を惜しまない] プログラマーの三大美徳「怠惰」 4
5. 楽をするために 理解しやすく変更しやすいシステムにする 利用できるものは使う テストを書く 自動化する ノウハウの共有 5
6. フレームワークで楽したい Web アプリケーション開発で便利なものが揃ってる ベースとなる処理フロー HTTP の扱い、RDBMS 等のミドルウェア操作 開発支援（テスト、データベースマイグレーション、デバッグ） 適度な制約 カスタマイズ無しで、そのままで使える ユーザが多いフレームワークは情報も多い 6
7. フレームワークとは 7
8. フレームワークとは How である 汎用的である ライフタイムがある 8
9. フレームワークは How である What = アプリケーションとして実装すべきもの ドメイン、関心事、仕様 How = What をどの技術でどう実装するか HTTP 、RDBMS 、メール、KVS 等 アプリケーションが主、フレームワークは従 9
10. フレームワークは汎用的である OSS フレームワークは、汎用のフレームワーク 自分たちのアプリケーション専用のものではない 要件に合うところは使い、合わないところは使わない 10
11. [ 例1] SQL を書くか問題 複雑なクエリを Eloquent や QueryBuilder で書くのが大変 SQL を書いて、それを Eloquent のコードに書き戻す不毛感 必要なら SQL 文を書く selectRaw() 、whereRaw() 、DB::statement() 等 Eloquent のメソッドに閉じて、局所化しておく 11
12. [ 例1] SQL 文を記述 Eloquent のメソッドに実装 呼び出す側は、SQL 文が書かれているかは知らなくて良い public function findTargetOrders(array $itemIds): iterable { $sql = <<<EOT SELECT * FROM orders WHERE (SELECT COUNT(*) FROM order_details WHERE orders.id=order_details.order_id AND order_details.item_id=? AND COUNT(*)>?) EOT; return $this->newQuery()->selectRaw($sql, $itemIds)->get(); } 12
13. [ 例2] 1 API だけを速度改善 フレームワーク上で動く Web アプリケーション キャンペーンで、1 API のみアクセスが急増する オンプレミス環境で、スケールアウトが容易ではない チューニングは行ったが、フレームワークのボトルネック 13
14. [ 例2] API を Plain PHP で再実装 フレームワークのボトルネックが解消されたのでアクセスを捌けた 他の API や機能はフレームワークを利用したまま 基本はフレームワーク実装、事情があれば外す 14
15. フレームワークはライフタイムがある メジャーバージョンアップ対応に大きな工数がかかる問題 アプリケーション仕様は変わってないのに！ アプリケーションは意外に長生きする サービスは終わっても、コードが流用されることも 要素技術は時代によって変わっていく フレームワーク、言語、アーキテクチャ（サーバーレスとかも） 15
16. フレームワークのアップグレード メジャーバージョンのアップグレードは意外に大変 国内では、早くに流行した CakePHP で多く見られる Laravel も数年後には同じことが起こりうる インハウスフレームワークでも同様 できる範囲で考えておきたい 16
17. 1 から再実装すれば良いんじゃない？ 小さなアプリケーションなら良いが、実際はそんなに単純ではない リライトへの反論（レガシーソフトウェア改善ガイド） 最初に明らかにしておくが、完全な書き直しは、ほとんど常によくないアイデアだと私は信じている。 ビッグ・リライト（レガシーソフトウェア改善ガイド） ビッグ・リライトに挑戦するなら、他の選択肢をすべて試した後のことだと思いたい。 17
18. フレームワークと適切な距離を取る 18
19. フレームワークと適切な距離を取る 利用するが過度に依存しない フレームワークに一蓮托生しないように 主体的にフレームワークをコントロールする 選択肢を残しておく [Clean Architecture 達人に学ぶソフトウェアの構造と設計] 19
20. [ 例3] 独自ディレクトリに実装 アプリケーションを独自ディレクトリに実装 namespace も独自に定める app ディレクトリには必要最低限のみ記述 設定 ルーティング サービスコンテナ エラーハンドラ 20
21. [ 例3] 独自ディレクトリに実装 app/ # <--- Laravel アプリケーションディレクトリ（必要最低限のみ） packages/ # <--- 独自ディレクトリ Acme/ Point/ Controller/ Model/ Service/ Test/ 21
22. [ 例3] 独自 namespace composer.json に設定 ルーティングで独自 namespace を見るように設定 app/Providers/RouteServiceProvider.php //protected $namespace = 'App\Http\Controllers'; protected $namespace = ''; // 空文字にする routes/(api|web).php use App\Http\Actions\AddPoint\AddPointAction; $router->put('/customers/add_point', AddPointAction::class); 22
23. [ 例4] アプリケーションのレイヤを分ける コントローラ（Action 等）とアプリケーションロジックを分離 コントローラはフレームワークと密結合になりがち アプリケーションロジックは、別レイヤで実装 サービスレイヤ、ドメインレイヤ等 コントローラは、このレイヤの処理を呼ぶのみ レイヤによる責務（役割）を抑える 23
24. [ 例4] レイヤ分けのバリエーション MVC + サービスレイヤ DDD スタイルアーキテクチャ レイヤードアーキテクチャ クリーンアーキテクチャ 独立したコアレイヤパターン 24
25. サービスレイヤ https://www.slideshare.net/shin1x1/php-ver2-52828655 25
26. DDD スタイル レイヤードアーキテクチャ https://speakerdeck.com/shin1x1/201703-ddd-with-laravel 26
27. 独立したコアレイヤパターン https://speakerdeck.com/shin1x1/independent-core-layer-pattern- phpconsen2019 27
28. 事例: Laravel アップグレード Laravel 4.2 + PHP 5.6 から Laravel 5.5 + PHP 7.2 業務アプリケーション（SPA ） 入力フォーム、集計、帳票 独自ディレクトリ構成 サービスレイヤを追加し、アプリケーションロジックを実装 サービスレイヤは、Eloquent と密結合 28
29. 事例: Laravel アップグレード 独自ディレクトリは、そのままコピー 設定やコントローラ周りは大きく変更 サービスレイヤは、Eloquent に起因する箇所のみ変更 Eloquent の変更も少なめだったので助かった 分離していたおかげで、スムーズに進んだ テスト万歳！ 29
30. さいごに 30
31. フレームワークとの付き合い方 楽するためにフレームワークを使う フレームワークをコントロールする 主体的に技術を選ぶ、使う 31
32. Q? @shin1x1 32