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
ito_kohhh
November 09, 2025
Programming
0
2.8k
Eloquentを使ってどこまでコードの治安を保てるのか?を新人が考察してみた
ito_kohhh
November 09, 2025
Tweet
Share
Other Decks in Programming
See All in Programming
Swift Concurrency 年表クイズ
omochi
3
220
Vueのバリデーション、結局どれを選べばいい? ― 自作バリデーションの限界と、脱却までの道のり ― / Which Vue Validation Library Should We Really Use? The Limits of Self-Made Validation and How I Finally Moved On
neginasu
3
1.8k
組織もソフトウェアも難しく考えない、もっとシンプルな考え方で設計する #phpconfuk
o0h
PRO
6
1.5k
自動テストのアーキテクチャとその理由ー大規模ゲーム開発の場合ー
segadevtech
0
510
One Enishi After Another
snoozer05
PRO
0
180
SwiftDataを使って10万件のデータを読み書きする
akidon0000
0
250
Verilator + Rust + gRPC と Efinix の RISC-V でAIアクセラレータをAIで作ってる話 RTLを語る会(18) 2025/11/08
ryuz88
0
260
Pythonに漸進的に型をつける
nealle
1
160
Researchlyの開発で参考にしたデザイン
adsholoko
0
110
CSC509 Lecture 07
javiergs
PRO
0
260
AIのバカさ加減に怒る前にやっておくこと
blueeventhorizon
0
150
AI時代に必須!状況言語化スキル / ai-context-verbalization
minodriven
2
330
Featured
See All Featured
How STYLIGHT went responsive
nonsquared
100
5.9k
YesSQL, Process and Tooling at Scale
rocio
174
15k
The Pragmatic Product Professional
lauravandoore
36
7k
Building Flexible Design Systems
yeseniaperezcruz
329
39k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
9
960
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.3k
Embracing the Ebb and Flow
colly
88
4.9k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
132
19k
The Invisible Side of Design
smashingmag
302
51k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
35
3.2k
Done Done
chrislema
186
16k
The Power of CSS Pseudo Elements
geoffreycrofte
80
6k
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