Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
実運用におけるLaravelとNuxtでのRepositoryのレイヤ分割の話
Search
Shohei Kondo
January 31, 2019
Programming
3
3.6k
実運用におけるLaravelとNuxtでのRepositoryのレイヤ分割の話
Laravel/Vue.js勉強会#7 資料
Twitter:
https://twitter.com/korn_shonery
Blog:
https://blog.kon-shou.com/
Shohei Kondo
January 31, 2019
Tweet
Share
More Decks by Shohei Kondo
See All by Shohei Kondo
Serverless 入門 ~環境構築からデプロイまで~
kon_shou
0
350
Other Decks in Programming
See All in Programming
Introducing ReActionView: A new ActionView-Compatible ERB Engine @ Kaigi on Rails 2025, Tokyo, Japan
marcoroth
3
1k
PHPに関数型の魂を宿す〜PHP 8.5 で実現する堅牢なコードとは〜 #phpcon_hiroshima / phpcon-hiroshima-2025
shogogg
1
240
All About Angular's New Signal Forms
manfredsteyer
PRO
0
170
Writing Better Go: Lessons from 10 Code Reviews
konradreiche
0
1.3k
スマホから Youtube Shortsを見られないようにする
lemolatoon
27
32k
uniqueパッケージの内部実装を支えるweak pointerの話
magavel
0
1k
CSC509 Lecture 04
javiergs
PRO
0
300
CSC305 Lecture 05
javiergs
PRO
0
220
Android16 Migration Stories ~Building a Pattern for Android OS upgrades~
reoandroider
0
110
なぜあの開発者はDevRelに伴走し続けるのか / Why Does That Developer Keep Running Alongside DevRel?
nrslib
3
410
はじめてのDSPy - 言語モデルを『プロンプト』ではなく『プログラミング』するための仕組み
masahiro_nishimi
2
510
技術的負債の正体を知って向き合う / Facing Technical Debt
irof
0
180
Featured
See All Featured
10 Git Anti Patterns You Should be Aware of
lemiorhan
PRO
657
61k
Why Our Code Smells
bkeepers
PRO
340
57k
Done Done
chrislema
185
16k
Practical Tips for Bootstrapping Information Extraction Pipelines
honnibal
PRO
23
1.5k
Measuring & Analyzing Core Web Vitals
bluesmoon
9
620
No one is an island. Learnings from fostering a developers community.
thoeni
21
3.5k
個人開発の失敗を避けるイケてる考え方 / tips for indie hackers
panda_program
115
20k
Designing Experiences People Love
moore
142
24k
GraphQLとの向き合い方2022年版
quramy
49
14k
Designing for Performance
lara
610
69k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
49
3.1k
Creating an realtime collaboration tool: Agile Flush - .NET Oxford
marcduiker
33
2.3k
Transcript
実運⽤における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<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} が叩かれる
ここから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<Warehousing> { 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 を⽬指していこうぜ!