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

Transcript

1. Eloquentを使ってどこまでコードの治安 を保てるのか？ を新人が考察してみた 株式会社クイック Web事業企画開発本部 伊藤滉暉（@ito_kohhh） 1/28
2. 自己紹介 伊藤滉暉（@ito_kohhh） 株式会社クイック Web事業企画開発本部 社内で使用する業務アプリケーションの開発 PHPを触り始めて1年半くらい 2/28
3. アジェンダ 【起】前提の共有 【承】参考にした設計方針の紹介 【転】さらなる考慮の必要性 【結】+αの検討・提案 3/28
4. 【起】前提の共有 4/28
5. 既存のコードベース Laravel×Reactのプロジェクト 全体的にトランザクショナルなコードが多い 各手続きの中に共通的な処理があるはずなのに 同じような処理が分散している 【起】前提の共有 5/28
6. 既存のコードベース Laravel×Reactのプロジェクト 全体的にトランザクショナルなコードが多い 各手続きの中に共通的な処理があるはずなのに 同じような処理が分散している →凝集度が低い状態 【起】前提の共有 6/28
7. 今後の実装方針についての検討 今後のアーキテクチャについてメンバー内で議論 そもそもLaravelのEloquentに依存しない形にする？ リポジトリの導入など でもEloquentに依存しないようにすると実装コストが かかるのでは 【起】前提の共有 7/28
8. 今後の実装方針についての検討 今後のアーキテクチャについてメンバー内で議論 そもそもLaravelのEloquentに依存しない形にする？ リポジトリの導入など でもEloquentに依存しないようにすると実装コストが かかるのでは →まずはLaravelの機能を活用する方向を目指せないか？ 【起】前提の共有 8/28
9. 【承】参考にした設計方針の紹介 9/28
10. 「なんちゃってクリーンアーキテクチャ」 既存のLaravel Wayに加えて、 app/UseCase のディレクトリに ドメインごとの単一責務な クラスを作成する UseCase 内ではEloquentモデル に依存することを許容する https://zenn.dev/mpyw/articles/ce7d09eb6d8117 【承】参考にした設計方針の紹介 10/28
11. 【転】さらなる考慮ポイント 11/28
12. 「なんちゃってクリーンアーキテクチャ」の先 UseCaseごとに単一責務 【転】さらなる考慮ポイント 12/28
13. 「なんちゃってクリーンアーキテクチャ」の先 UseCaseごとに単一責務 ＝最小限のクラス分割で、最大限の保守性が期待できる 【転】さらなる考慮ポイント 13/28
14. 「なんちゃってクリーンアーキテクチャ」の先 UseCaseごとに単一責務 ＝最小限のクラス分割で、最大限の保守性が期待できる →アプリケーションが成長してきたら？を考える 【転】さらなる考慮ポイント 14/28
15. ユースケースが増えてきたら？ 例：ユーザーの退会処理 ユーザーが、自分の意思で退会する 管理者が、ユーザーを退会させる 一定期間操作のないユーザーをシステムが退会させる 【転】さらなる考慮ポイント 15/28
16. ユースケースが増えてきたら？ 例：ユーザーの退会処理 ユーザーが、自分の意思で退会する 管理者が、ユーザーを退会させる 一定期間操作のないユーザーをシステムが退会させる →どの場合もユーザーが退会しているが、異なるユースケース 【転】さらなる考慮ポイント 16/28
17. 同じような処理が分散する ユースケース間で似たような処理がある場合 「なんちゃってクリーンアーキテクチャ」だけでは 同じような処理が分散して書かれることになる 【転】さらなる考慮ポイント 17/28
18. 同じような処理が分散する ユースケース間で似たような処理がある場合 「なんちゃってクリーンアーキテクチャ」だけでは 同じような処理が分散して書かれることになる →これを繰り返すと、結局最初のコードベースと同じになる 【転】さらなる考慮ポイント 18/28
19. 【結】+αの検討・提案 19/28
20. モデルにメソッドを切り出す 【結】+αの検討・提案 20/28
21. モデルにメソッドを切り出す あらゆる処理をモデルに記述する 「なんちゃってクリーンアーキテクチャ」ではアンチパターンとしている 【結】+αの検討・提案 21/28
22. モデルにメソッドを切り出す あらゆる処理をモデルに記述する 「なんちゃってクリーンアーキテクチャ」ではアンチパターンとしている ユースケースを単一責務にした上で 必要に応じてモデルにメソッドを切り出す 【結】+αの検討・提案 22/28
23. メソッドを切り出す時の判断基準 【結】+αの検討・提案 23/28
24. メソッドを切り出す時の判断基準 モデルに持たせて自然な処理である メソッド名がドメインの言葉で表現できる 元々Eloquentが持つメソッド名とも衝突しにくい 【結】+αの検討・提案 24/28
25. メソッドを切り出す時の判断基準 モデルに持たせて自然な処理である メソッド名がドメインの言葉で表現できる 元々Eloquentが持つメソッド名とも衝突しにくい 複数のユースケースで共有されることが見込める 現時点で単一のユースケースでしか使われないのであれば あえてモデルに持たせなくても良い 【結】+αの検討・提案 25/28
26. メソッドを切り出す時の判断基準 モデルに持たせて自然な処理である メソッド名がドメインの言葉で表現できる 元々Eloquentが持つメソッド名とも衝突しにくい 複数のユースケースで共有されることが見込める 現時点で単一のユースケースでしか使われないのであれば あえてモデルに持たせなくても良い →凝集度の高い状態を維持できる 【結】+αの検討・提案 26/28
27. まとめ Laravelなら、Eloquentとうまく付き合いたい 「なんちゃってクリーンアーキテクチャ」＋αの提案 まずはLaravel Wayに乗る 1アクションに対応した単一責務のユースケース その上でモデルが持っていて自然な処理は モデルに持たせて共通化 27/28
28. まとめ Laravelなら、Eloquentとうまく付き合いたい 「なんちゃってクリーンアーキテクチャ」＋αの提案 まずはLaravel Wayに乗る 1アクションに対応した単一責務のユースケース その上でモデルが持っていて自然な処理は モデルに持たせて共通化 →まだ検証途中なので、懇親会でぜひお話しさせてください！ 28/28