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

Laravel × レイヤードアーキテクチャをやってみている話 / Trying Laravel with layered architecture

Laravel × レイヤードアーキテクチャをやってみている話 / Trying Laravel with layered architecture

2018-05-30 開催の「第126回 PHP勉強会@東京」におけるLT資料です

https://phpstudy.doorkeeper.jp/events/74677

Shohei Okada

May 30, 2018
Tweet

More Decks by Shohei Okada

Other Decks in Programming

Transcript

  1. Laravel
    ×
    レイヤードアーキテクチャ
    をやってみている話
    第126回 PHP勉強会@東京

    View Slide

  2. 岡田 正平(おかだ しょうへい)@okashoi
    • 株式会社ウィルゲート 2015年新卒入社
    • 開発室 ソリューションユニット 所属
    • PHP, Laravel, Vue.js
    2
    自己紹介
    Slides:

    View Slide

  3. • これまで CakePHP で開発してきたが、今回はじめて Laravel を採用
    • 技術のキャッチアップ
    • チームを越えられる人材育成
    • 別チームで Laravel をメインに使っていた私 に白羽の矢が立つ
    3
    背景|とあるチームの新規開発プロジェクト

    View Slide

  4. 4
    背景|とあるチームの新規開発プロジェクト
    プロジェクト
    リーダー
    実装者 2 名 インフラ担当
    • 別チームから兼任
    (稼動の 40%)
    • 実装方針の策定
    • Laravel の知見
    伝搬するマン

    View Slide

  5. 自分が提供できる価値を考える
    「チームはわざわざ『Laravel に切り替える』
    というコストを払っている……」

    View Slide

  6. 自分が提供できる価値を考える
    「なのに Laravel をただの MVC フレームワーク
    として使うのではメリットが薄いよね?」

    View Slide

  7. 「レイヤードアーキテクチャやろう」

    View Slide

  8. 8
    レイヤードアーキテクチャ?
    出典:DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel
    https://speakerdeck.com/shin1x1/ddd-with-laravel
    (めちゃくちゃ参考にさせてもらってます )

    View Slide

  9. 9
    レイヤードアーキテクチャ
    ※DDD(ドメイン駆動設計)と
    一緒に語られることが多いが
    今回は DDD はやっていない
    Domain 層はプレーンな PHP オブジェクトで実装
    Laravel 固有の知識・実際のデータ形式の情報などは
    Application, Infrastructure 層に寄せていく

    View Slide

  10. • Laravel 固有の知識がビジネスロジックに漏れ出ない(=関心の分離)
    • 例)Eloquent ORM の記述は Infrastructure 層で完結している
    • Laravel の ServiceContaner と相性がいい(後述)
    10
    うまくいっている点

    View Slide

  11. 出典:DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel
    by shin1x1
    https://speakerdeck.com/shin1x1/ddd-with-laravel?slide=40
    11
    うまくいっている点|Laravel との相性の良さ

    View Slide

  12. • ServiceProvider 内(UserImageRepository は interface)
    • 利用箇所(環境に依存しないコードになる)
    • DI になっているのでテストも書きやすい!
    12
    うまくいっている点|Laravel との相性の良さ
    if (app()->environment('production') || app()->environment('staging')) {
    // 本番環境・ステージング環境のみ、S3 に保存
    $this->app->bind(UserImageRepository::class, S3UserImageRepository::class);
    } else {
    // それ以外はローカルファイルストレージに保存
    $this->app->bind(UserImageRepository::class, LocalUserImageRepository::class);
    }
    public function __construct(UserRepository $userRepository, UserImageRepository $userImageRepository)
    {
    $this->userRepository = $userRepository;
    $this->userImageRepository = $userImageRepository;
    }

    View Slide

  13. • class 数が多くなるので煩雑に感じがち
    • 勘所を掴むまでは極端すぎるくらいでもいいかな、とも
    • うまく集約が使いこなせていない感
    • User という Domain Model のコンストラクタの引数が 26 個に
    • ユーザ名、性別、プロフィール画像、email などなど……
    13
    悩んでいる点

    View Slide

  14. • 今後、ビジネスロジックが増えてきたときに
    Domain 層に寄せていくようにチームの意識をすり合わせていく
    • 運用保守も始まったときに考え方が守られるかどうか
    ➢ 個人が考え、チームで議論できる土台・文化づくり
    14
    これから

    View Slide