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

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 を⽬指していこうぜ！