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

2019/02/16 Laravel JP Conference

Transcript

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

   View Slide

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

   View Slide

3. 楽をするため
   3
   

   View Slide

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

   View Slide

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

   View Slide

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

   View Slide

7. フレームワークとは
   7
   

   View Slide

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

   View Slide

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

   View Slide

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

    View Slide

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

    View Slide

12. [
    例1] SQL
    文を記述
    Eloquent
    のメソッドに実装
    呼び出す側は、SQL
    文が書かれているかは知らなくて良い
    public function findTargetOrders(array $itemIds): iterable
    {
    $sql = <<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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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
    

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

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

    View Slide

30. さいごに
    30
    

    View Slide

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

    View Slide

32. Q?
    @shin1x1
    32
    

    View Slide