Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

3,076 views

Published on

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

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

Published in: Software
  • Be the first to comment

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

  1. 1. Laravel × レイヤードアーキテクチャ をやってみている話 第126回 PHP勉強会@東京
  2. 2. 岡田 正平(おかだ しょうへい)@okashoi • 株式会社ウィルゲート 2015年新卒入社 • 開発室 ソリューションユニット 所属 • PHP, Laravel, Vue.js 2 自己紹介 Slides:
  3. 3. • これまで CakePHP で開発してきたが、今回はじめて Laravel を採用 • 技術のキャッチアップ • チームを越えられる人材育成 • 別チームで Laravel をメインに使っていた私 に白羽の矢が立つ 3 背景|とあるチームの新規開発プロジェクト
  4. 4. 4 背景|とあるチームの新規開発プロジェクト プロジェクト リーダー 実装者 2 名 インフラ担当 • 別チームから兼任 (稼動の 40%) • 実装方針の策定 • Laravel の知見 伝搬するマン
  5. 5. 自分が提供できる価値を考える 「チームはわざわざ『Laravel に切り替える』 というコストを払っている……」
  6. 6. 自分が提供できる価値を考える 「なのに Laravel をただの MVC フレームワーク として使うのではメリットが薄いよね?」
  7. 7. 「レイヤードアーキテクチャやろう」
  8. 8. 8 レイヤードアーキテクチャ? 出典:DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel https://speakerdeck.com/shin1x1/ddd-with-laravel (めちゃくちゃ参考にさせてもらってます )
  9. 9. 9 レイヤードアーキテクチャ ※DDD(ドメイン駆動設計)と 一緒に語られることが多いが 今回は DDD はやっていない Domain 層はプレーンな PHP オブジェクトで実装 Laravel 固有の知識・実際のデータ形式の情報などは Application, Infrastructure 層に寄せていく
  10. 10. • Laravel 固有の知識がビジネスロジックに漏れ出ない(=関心の分離) • 例)Eloquent ORM の記述は Infrastructure 層で完結している • Laravel の ServiceContaner と相性がいい(後述) 10 うまくいっている点
  11. 11. 出典:DDDパターンを活用した Laravelアプリケーション開発/ddd-with-laravel by shin1x1 https://speakerdeck.com/shin1x1/ddd-with-laravel?slide=40 11 うまくいっている点|Laravel との相性の良さ
  12. 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; }
  13. 13. • class 数が多くなるので煩雑に感じがち • 勘所を掴むまでは極端すぎるくらいでもいいかな、とも • うまく集約が使いこなせていない感 • User という Domain Model のコンストラクタの引数が 26 個に • ユーザ名、性別、プロフィール画像、email などなど…… 13 悩んでいる点
  14. 14. • 今後、ビジネスロジックが増えてきたときに Domain 層に寄せていくようにチームの意識をすり合わせていく • 運用保守も始まったときに考え方が守られるかどうか ➢ 個人が考え、チームで議論できる土台・文化づくり 14 これから

×