Eloquentを使ってどこまでコードの治安を保てるのか？を新人が考察してみた

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

Eloquentを使ってどこまでコードの治安を保てるのか？を新人が考察してみた

Eloquentを使ってどこまでコードの治安を保てるのか？を新人が考察してみた

ito_kohhh

Other Decks in Programming

Featured

Transcript