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

Ca17a082a30f4cbfed1d0a6dacbe3af2?s=47 shin1x1
February 16, 2019

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

2019/02/16 Laravel JP Conference

Ca17a082a30f4cbfed1d0a6dacbe3af2?s=128

shin1x1

February 16, 2019
Tweet

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