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
Eloquentを使ってどこまでコードの治安を保てるのか?を新人が考察してみた
Search
Sponsored
·
Your Podcast. Everywhere. Effortlessly.
Share. Educate. Inspire. Entertain. You do you. We'll handle the rest.
→
ito_kohhh
November 09, 2025
Programming
0
3.3k
Eloquentを使ってどこまでコードの治安を保てるのか?を新人が考察してみた
ito_kohhh
November 09, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
PJのドキュメントを全部Git管理にしたら、一番喜んだのはAIだった
nanaism
0
250
ふつうの Rubyist、ちいさなデバイス、大きな一年
bash0c7
0
780
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
470
AI活用のコスパを最大化する方法
ochtum
0
130
ご飯食べながらエージェントが開発できる。そう、Agentic Engineeringならね。
yokomachi
1
290
DevinとClaude Code、SREの現場で使い倒してみた件
karia
1
990
Agent Skills Workshop - AIへの頼み方を仕組み化する
gotalab555
15
8.3k
nuget-server - あなたが必要だったNuGetサーバー
kekyo
PRO
0
220
Unity6.3 AudioUpdate
cova8bitdots
0
120
エラーログのマスキングの仕組みづくりに役立ったASTの話
kumoichi
0
160
Cyrius ーLinux非依存にコンテナをネイティブ実行する専用OSー
n4mlz
0
120
The Past, Present, and Future of Enterprise Java
ivargrimstad
0
370
Featured
See All Featured
Fashionably flexible responsive web design (full day workshop)
malarkey
408
66k
Bootstrapping a Software Product
garrettdimon
PRO
307
120k
The #1 spot is gone: here's how to win anyway
tamaranovitovic
2
980
Thoughts on Productivity
jonyablonski
75
5.1k
Prompt Engineering for Job Search
mfonobong
0
180
[RailsConf 2023] Rails as a piece of cake
palkan
59
6.4k
SEO in 2025: How to Prepare for the Future of Search
ipullrank
3
3.4k
The Art of Programming - Codeland 2020
erikaheidi
57
14k
Amusing Abliteration
ianozsvald
0
130
Marketing to machines
jonoalderson
1
5k
Git: the NoSQL Database
bkeepers
PRO
432
66k
Avoiding the “Bad Training, Faster” Trap in the Age of AI
tmiket
0
97
Transcript
Eloquentを使ってどこまでコードの治安 を保てるのか? を新人が考察してみた 株式会社クイック Web事業企画開発本部 伊藤滉暉(@ito_kohhh) 1/28
自己紹介 伊藤滉暉(@ito_kohhh) 株式会社クイック Web事業企画開発本部 社内で使用する業務アプリケーションの開発 PHPを触り始めて1年半くらい 2/28
アジェンダ 【起】前提の共有 【承】参考にした設計方針の紹介 【転】さらなる考慮の必要性 【結】+αの検討・提案 3/28
【起】前提の共有 4/28
既存のコードベース Laravel×Reactのプロジェクト 全体的にトランザクショナルなコードが多い 各手続きの中に共通的な処理があるはずなのに 同じような処理が分散している 【起】前提の共有 5/28
既存のコードベース Laravel×Reactのプロジェクト 全体的にトランザクショナルなコードが多い 各手続きの中に共通的な処理があるはずなのに 同じような処理が分散している →凝集度が低い状態 【起】前提の共有 6/28
今後の実装方針についての検討 今後のアーキテクチャについてメンバー内で議論 そもそもLaravelのEloquentに依存しない形にする? リポジトリの導入など でもEloquentに依存しないようにすると実装コストが かかるのでは 【起】前提の共有 7/28
今後の実装方針についての検討 今後のアーキテクチャについてメンバー内で議論 そもそもLaravelのEloquentに依存しない形にする? リポジトリの導入など でもEloquentに依存しないようにすると実装コストが かかるのでは →まずはLaravelの機能を活用する方向を目指せないか? 【起】前提の共有 8/28
【承】参考にした設計方針の紹介 9/28
「なんちゃってクリーンアーキテクチャ」 既存のLaravel Wayに加えて、 app/UseCase のディレクトリに ドメインごとの単一責務な クラスを作成する UseCase 内ではEloquentモデル に依存することを許容する
https://zenn.dev/mpyw/articles/ce7d09eb6d8117 【承】参考にした設計方針の紹介 10/28
【転】さらなる考慮ポイント 11/28
「なんちゃってクリーンアーキテクチャ」の先 UseCaseごとに単一責務 【転】さらなる考慮ポイント 12/28
「なんちゃってクリーンアーキテクチャ」の先 UseCaseごとに単一責務 =最小限のクラス分割で、最大限の保守性が期待できる 【転】さらなる考慮ポイント 13/28
「なんちゃってクリーンアーキテクチャ」の先 UseCaseごとに単一責務 =最小限のクラス分割で、最大限の保守性が期待できる →アプリケーションが成長してきたら?を考える 【転】さらなる考慮ポイント 14/28
ユースケースが増えてきたら? 例:ユーザーの退会処理 ユーザーが、自分の意思で退会する 管理者が、ユーザーを退会させる 一定期間操作のないユーザーをシステムが退会させる 【転】さらなる考慮ポイント 15/28
ユースケースが増えてきたら? 例:ユーザーの退会処理 ユーザーが、自分の意思で退会する 管理者が、ユーザーを退会させる 一定期間操作のないユーザーをシステムが退会させる →どの場合もユーザーが退会しているが、異なるユースケース 【転】さらなる考慮ポイント 16/28
同じような処理が分散する ユースケース間で似たような処理がある場合 「なんちゃってクリーンアーキテクチャ」だけでは 同じような処理が分散して書かれることになる 【転】さらなる考慮ポイント 17/28
同じような処理が分散する ユースケース間で似たような処理がある場合 「なんちゃってクリーンアーキテクチャ」だけでは 同じような処理が分散して書かれることになる →これを繰り返すと、結局最初のコードベースと同じになる 【転】さらなる考慮ポイント 18/28
【結】+αの検討・提案 19/28
モデルにメソッドを切り出す 【結】+αの検討・提案 20/28
モデルにメソッドを切り出す あらゆる処理をモデルに記述する 「なんちゃってクリーンアーキテクチャ」ではアンチパターンとしている 【結】+αの検討・提案 21/28
モデルにメソッドを切り出す あらゆる処理をモデルに記述する 「なんちゃってクリーンアーキテクチャ」ではアンチパターンとしている ユースケースを単一責務にした上で 必要に応じてモデルにメソッドを切り出す 【結】+αの検討・提案 22/28
メソッドを切り出す時の判断基準 【結】+αの検討・提案 23/28
メソッドを切り出す時の判断基準 モデルに持たせて自然な処理である メソッド名がドメインの言葉で表現できる 元々Eloquentが持つメソッド名とも衝突しにくい 【結】+αの検討・提案 24/28
メソッドを切り出す時の判断基準 モデルに持たせて自然な処理である メソッド名がドメインの言葉で表現できる 元々Eloquentが持つメソッド名とも衝突しにくい 複数のユースケースで共有されることが見込める 現時点で単一のユースケースでしか使われないのであれば あえてモデルに持たせなくても良い 【結】+αの検討・提案 25/28
メソッドを切り出す時の判断基準 モデルに持たせて自然な処理である メソッド名がドメインの言葉で表現できる 元々Eloquentが持つメソッド名とも衝突しにくい 複数のユースケースで共有されることが見込める 現時点で単一のユースケースでしか使われないのであれば あえてモデルに持たせなくても良い →凝集度の高い状態を維持できる 【結】+αの検討・提案 26/28
まとめ Laravelなら、Eloquentとうまく付き合いたい 「なんちゃってクリーンアーキテクチャ」+αの提案 まずはLaravel Wayに乗る 1アクションに対応した単一責務のユースケース その上でモデルが持っていて自然な処理は モデルに持たせて共通化 27/28
まとめ Laravelなら、Eloquentとうまく付き合いたい 「なんちゃってクリーンアーキテクチャ」+αの提案 まずはLaravel Wayに乗る 1アクションに対応した単一責務のユースケース その上でモデルが持っていて自然な処理は モデルに持たせて共通化 →まだ検証途中なので、懇親会でぜひお話しさせてください! 28/28