Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

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

Slide 5

Slide 5 text

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

Slide 6

Slide 6 text

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

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

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

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

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

Slide 11

Slide 11 text

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

Slide 12

Slide 12 text

• 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; }

Slide 13

Slide 13 text

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

Slide 14

Slide 14 text

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