実運⽤におけるLaravel とNuxt での Repository のレイヤ分割の話 @Laravel/Vue.js 勉強会#7 By kon-shou

⾃⼰＆会社紹介 ⾃⼰ Laravel: 1 年7 ヶ⽉ Nuxt: 11 ヶ⽉ 会社 会社名: オープンロジ 業種: 物流アウトソーシング Laravel+react x1 Laravel+Nuxt.js x2

アジェンダ 1. よく⾒るレイヤー構造の話 1min 2. オープンロジの場合の話 7min 3. Pros/ Cons 2min

（たぶん）よく⾒る画像

なるほど... ？ で、実際どうやんの？

オープンロジの場合 届いた荷物(Warehousing) を システムで⾒たい 届いた荷物にID (WarehousingId) が貼ってあるよ！

データフローの概略図

Nuxt の世界のお話

pages/warehousings/_id.vue pages ├── home ├── items │ └── _id ├── schedules │ └── warehousings │ └── _id │ └── fix ├── shippings │ └── _id └── warehousings └── _id ブラウザから https://openlogi.web.example.com/warehousings/${warehousingId} にアクセス

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) が実⾏される

warehousingRepository.find() async find(warehousingId): Promise { 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} が叩かれる

ここからLaravel の世界のお話

今どこの話してるんだ... ？ => Laravel/WarehousingContoller から Mysql を⽬指す

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 を呼ぶ

Domains/Warehousing/WarehousingRepository public function find($id) { return Warehousing::find($id); } ここでやるのは、モデルを⽣成して返すだけ 今のところ は... ( 伏線)

今どこの話してるんだ... ？

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; } 帰ってきたモデルをいい感じに 整形 する

ふたたびNuxt の世界のお話

再掲 warehousingRepository.find() async find(warehousingId): Promise { const response = await this.axios.get(`/warehousings/${warehousingId}`); return new Warehousing(response.data); } Laravel の WarehousingPresenter で整形したデータ (=response.data) からモデルを作る => そのモデルを pages/warehousings/_id/index に返す

再掲 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 タグ内で描写する。完！

あれ？何か良いことあるんだっけ？

実は、本当はrepository から⾊々と呼んでます

メリット 変更が発⽣した場合に、 修正範囲が狭まる データを取得するソース（DB/ElasticSearch/API/etc... ）の変更が⽣ じた場合に、Repository だけを修正すればいい フロントに渡すデータを整形したい場合に、Presenter だけを修正す ればいい カッコよく⾔えば プログラムの責務分担を明確にできる

デメリット 初⾒殺し Join したばかりだとキャッチアップコストが上がっちゃう... 実装量が増えがち ドメインの切り⽅に迷う 「Warehousing のサブクラスは別クラスでやるべき？それとも Warehousing と同じ？？」

でもメリットでかいよ！ みんなも⾊々考えて Clean なArchitecture を⽬指していこうぜ！