Upgrade to Pro — share decks privately, control downloads, hide ads and more …

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

shin1x1
PRO
February 16, 2019

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

2019/02/16 Laravel JP Conference

shin1x1
PRO

February 16, 2019
Tweet

More Decks by shin1x1

Other Decks in Technology

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