実運用におけるLaravelとNuxtでのRepositoryのレイヤ分割の話

Laravel/Vue.js勉強会#7 資料

Twitter: https://twitter.com/korn_shonery
Blog: https://blog.kon-shou.com/

Transcript

1. 実運⽤におけるLaravel とNuxt での Repository のレイヤ分割の話 @Laravel/Vue.js 勉強会#7 By kon-shou
2. ⾃⼰＆会社紹介 ⾃⼰ Laravel: 1 年7 ヶ⽉ Nuxt: 11 ヶ⽉ 会社 会社名: オープンロジ 業種: 物流アウトソーシング Laravel+react x1 Laravel+Nuxt.js x2
3. アジェンダ 1. よく⾒るレイヤー構造の話 1min 2. オープンロジの場合の話 7min 3. Pros/ Cons 2min
4. （たぶん）よく⾒る画像
5. なるほど... ？ で、実際どうやんの？
6. オープンロジの場合 届いた荷物(Warehousing) を システムで⾒たい 届いた荷物にID (WarehousingId) が貼ってあるよ！
7. データフローの概略図
8. Nuxt の世界のお話
9. pages/warehousings/_id.vue pages ├── home ├── items │ └── _id ├── schedules │ └── warehousings │ └── _id │ └── fix ├── shippings │ └── _id └── warehousings └── _id ブラウザから https://openlogi.web.example.com/warehousings/${warehousingId} にアクセス
10. warehousings/_id/index のasyncData() が呼ばれる async asyncData({ app, params, query }) { const warehousingRepository = app.$serviceProvider.get('WarehousingRepository'); const warehousingId = _.get(params, 'id'); const warehousing = await warehousingRepository.find(warehousingId); return { warehousing, }; } 真っ先に呼ばれる asyncData() で warehousingRepository. nd(warehousingId) が実⾏される
11. warehousingRepository.find() async find(warehousingId): Promise<Warehousing> { const response = await this.axios.get(`/warehousings/${warehousingId}`); return new Warehousing(response.data); } nuxt.con g.js で this.axios.get をapi サーバーに向けている => https://openlogi.api.example.com/warehousings/${warehousingId} が叩かれる
12. ここからLaravel の世界のお話
13. 今どこの話してるんだ... ？ => Laravel/WarehousingContoller から Mysql を⽬指す
14. H p/Controllers/WarehousingController routing を経て show() に到達 public function show($warehousingId): Warehousing { $warehousing = $this->warehousingRepository->find($warehousingId); if (!$warehousing) { throw new HttpNotFoundException(' 指定された⼊荷が⾒つかりませんでした'); } return $warehousing; } Laravel 側でも、再度 warehousingRepository を呼ぶ
15. Domains/Warehousing/WarehousingRepository public function find($id) { return Warehousing::find($id); } ここでやるのは、モデルを⽣成して返すだけ 今のところ は... ( 伏線)
16. 今どこの話してるんだ... ？
17. En tyPresenters/Domains/Warehousing/ WarehousingPresenter public function toApi($warehousing): array { $array = $warehousing->toArray(); $array['warehousing_items'] = $warehousing->warehousingItems ->map(function (WarehousingItem $warehousingItem) { return $this->warehousingItemPresenter->toApi($warehousingItem); } ); return $array; } 帰ってきたモデルをいい感じに 整形 する
18. ふたたびNuxt の世界のお話
19. 再掲 warehousingRepository.find() async find(warehousingId): Promise<Warehousing> { const response = await this.axios.get(`/warehousings/${warehousingId}`); return new Warehousing(response.data); } Laravel の WarehousingPresenter で整形したデータ (=response.data) からモデルを作る => そのモデルを pages/warehousings/_id/index に返す
20. 再掲 warehousings/_id/index.vue async asyncData({ app, params, query }) { const warehousingRepository = app.$serviceProvider.get('WarehousingRepository'); const warehousingId = _.get(params, 'id'); const warehousing = await warehousingRepository.find(warehousingId); return { warehousing, }; } ここで帰るwarehousing を template タグ内で描写する。完！
21. あれ？何か良いことあるんだっけ？
22. 実は、本当はrepository から⾊々と呼んでます
23. メリット 変更が発⽣した場合に、 修正範囲が狭まる データを取得するソース（DB/ElasticSearch/API/etc... ）の変更が⽣ じた場合に、Repository だけを修正すればいい フロントに渡すデータを整形したい場合に、Presenter だけを修正す ればいい カッコよく⾔えば プログラムの責務分担を明確にできる
24. デメリット 初⾒殺し Join したばかりだとキャッチアップコストが上がっちゃう... 実装量が増えがち ドメインの切り⽅に迷う 「Warehousing のサブクラスは別クラスでやるべき？それとも Warehousing と同じ？？」
25. でもメリットでかいよ！ みんなも⾊々考えて Clean なArchitecture を⽬指していこうぜ！