Tweet
Tweet

Slide 1

Slide 1 text

フレームワークとの付き合い方 2019/02/16 Laravel JP Conference @shin1x1

Slide 2

Slide 2 text

なぜフレームワークを使うのか？ 2

Slide 3

Slide 3 text

楽をするため 3

Slide 4

Slide 4 text

楽をするために全力を尽くす [ 全体の労力を減らすために手間を惜しまない] プログラマーの三大美徳「怠惰」 4

Slide 5

Slide 5 text

楽をするために 理解しやすく変更しやすいシステムにする 利用できるものは使う テストを書く 自動化する ノウハウの共有 5

Slide 6

Slide 6 text

フレームワークで楽したい Web アプリケーション開発で便利なものが揃ってる ベースとなる処理フロー HTTP の扱い、RDBMS 等のミドルウェア操作 開発支援（テスト、データベースマイグレーション、デバッグ） 適度な制約 カスタマイズ無しで、そのままで使える ユーザが多いフレームワークは情報も多い 6

Slide 7

Slide 7 text

フレームワークとは 7

Slide 8

Slide 8 text

フレームワークとは How である 汎用的である ライフタイムがある 8

Slide 9

Slide 9 text

フレームワークは How である What = アプリケーションとして実装すべきもの ドメイン、関心事、仕様 How = What をどの技術でどう実装するか HTTP 、RDBMS 、メール、KVS 等 アプリケーションが主、フレームワークは従 9

Slide 10

Slide 10 text

フレームワークは汎用的である OSS フレームワークは、汎用のフレームワーク 自分たちのアプリケーション専用のものではない 要件に合うところは使い、合わないところは使わない 10

Slide 11

Slide 11 text

[ 例1] SQL を書くか問題 複雑なクエリを Eloquent や QueryBuilder で書くのが大変 SQL を書いて、それを Eloquent のコードに書き戻す不毛感 必要なら SQL 文を書く selectRaw() 、whereRaw() 、DB::statement() 等 Eloquent のメソッドに閉じて、局所化しておく 11

Slide 12

Slide 12 text

[ 例1] SQL 文を記述 Eloquent のメソッドに実装 呼び出す側は、SQL 文が書かれているかは知らなくて良い public function findTargetOrders(array $itemIds): iterable { $sql = <<?) EOT; return $this->newQuery()->selectRaw($sql, $itemIds)->get(); } 12

Slide 13

Slide 13 text

[ 例2] 1 API だけを速度改善 フレームワーク上で動く Web アプリケーション キャンペーンで、1 API のみアクセスが急増する オンプレミス環境で、スケールアウトが容易ではない チューニングは行ったが、フレームワークのボトルネック 13

Slide 14

Slide 14 text

[ 例2] API を Plain PHP で再実装 フレームワークのボトルネックが解消されたのでアクセスを捌けた 他の API や機能はフレームワークを利用したまま 基本はフレームワーク実装、事情があれば外す 14

Slide 15

Slide 15 text

フレームワークはライフタイムがある メジャーバージョンアップ対応に大きな工数がかかる問題 アプリケーション仕様は変わってないのに！ アプリケーションは意外に長生きする サービスは終わっても、コードが流用されることも 要素技術は時代によって変わっていく フレームワーク、言語、アーキテクチャ（サーバーレスとかも） 15

Slide 16

Slide 16 text

フレームワークのアップグレード メジャーバージョンのアップグレードは意外に大変 国内では、早くに流行した CakePHP で多く見られる Laravel も数年後には同じことが起こりうる インハウスフレームワークでも同様 できる範囲で考えておきたい 16

Slide 17

Slide 17 text

1 から再実装すれば良いんじゃない？ 小さなアプリケーションなら良いが、実際はそんなに単純ではない リライトへの反論（レガシーソフトウェア改善ガイド） 最初に明らかにしておくが、完全な書き直しは、ほとんど常によくないアイデアだと私は信じている。 ビッグ・リライト（レガシーソフトウェア改善ガイド） ビッグ・リライトに挑戦するなら、他の選択肢をすべて試した後のことだと思いたい。 17

Slide 18

Slide 18 text

フレームワークと適切な距離を取る 18

Slide 19

Slide 19 text

フレームワークと適切な距離を取る 利用するが過度に依存しない フレームワークに一蓮托生しないように 主体的にフレームワークをコントロールする 選択肢を残しておく [Clean Architecture 達人に学ぶソフトウェアの構造と設計] 19

Slide 20

Slide 20 text

[ 例3] 独自ディレクトリに実装 アプリケーションを独自ディレクトリに実装 namespace も独自に定める app ディレクトリには必要最低限のみ記述 設定 ルーティング サービスコンテナ エラーハンドラ 20

Slide 21

Slide 21 text

[ 例3] 独自ディレクトリに実装 app/ # <--- Laravel アプリケーションディレクトリ（必要最低限のみ） packages/ # <--- 独自ディレクトリ Acme/ Point/ Controller/ Model/ Service/ Test/ 21

Slide 22

Slide 22 text

[ 例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

Slide 23

Slide 23 text

[ 例4] アプリケーションのレイヤを分ける コントローラ（Action 等）とアプリケーションロジックを分離 コントローラはフレームワークと密結合になりがち アプリケーションロジックは、別レイヤで実装 サービスレイヤ、ドメインレイヤ等 コントローラは、このレイヤの処理を呼ぶのみ レイヤによる責務（役割）を抑える 23

Slide 24

Slide 24 text

[ 例4] レイヤ分けのバリエーション MVC + サービスレイヤ DDD スタイルアーキテクチャ レイヤードアーキテクチャ クリーンアーキテクチャ 独立したコアレイヤパターン 24

Slide 25

Slide 25 text

サービスレイヤ https://www.slideshare.net/shin1x1/php-ver2-52828655 25

Slide 26

Slide 26 text

DDD スタイル レイヤードアーキテクチャ https://speakerdeck.com/shin1x1/201703-ddd-with-laravel 26

Slide 27

Slide 27 text

独立したコアレイヤパターン https://speakerdeck.com/shin1x1/independent-core-layer-pattern- phpconsen2019 27

Slide 28

Slide 28 text

事例: Laravel アップグレード Laravel 4.2 + PHP 5.6 から Laravel 5.5 + PHP 7.2 業務アプリケーション（SPA ） 入力フォーム、集計、帳票 独自ディレクトリ構成 サービスレイヤを追加し、アプリケーションロジックを実装 サービスレイヤは、Eloquent と密結合 28

Slide 29

Slide 29 text

事例: Laravel アップグレード 独自ディレクトリは、そのままコピー 設定やコントローラ周りは大きく変更 サービスレイヤは、Eloquent に起因する箇所のみ変更 Eloquent の変更も少なめだったので助かった 分離していたおかげで、スムーズに進んだ テスト万歳！ 29

Slide 30

Slide 30 text

さいごに 30

Slide 31

Slide 31 text

フレームワークとの付き合い方 楽するためにフレームワークを使う フレームワークをコントロールする 主体的に技術を選ぶ、使う 31

Slide 32

Slide 32 text

Q? @shin1x1 32