凝集性から考えるLaravelのmiddleware、routingに書くか？ Policyに書くか？

▼概要
Laravelでは「運営ユーザのみアクセスできる」などの認可をmiddlewareを使って簡単に定義できます。
定義の仕方も「routingファイルに書く」・「Policyを使う」など様々な用途で使い分けができます。 便利ですよね。

しかし、上のような書き方だと、どうしてもroute側かPolicy側が認可の責務を持つことになってしまいます。
もしかしたらValueObject・Entityを使う設計がされているプロダクトではValueObject・Entityごとに対する操作の認可というアプローチもありなのかもしれません！

このLTでは、ValueObject・Entityごとに対する操作の認可の実際の書き方・書くことでどういうメリットがあるかをお話します！

Transcript

1. 　　　　から考えるLaravelの middleware、 　　　　　に書くか？ 　　　　に書くか？ PHPカンファレンス福岡2024 凝集性 routing Policy @NobleNomad
2. 1. 自己紹介
3. 自己紹介
4. 結論 Entityごとに対する操作で認可行う → Enittyの凝集性が高まる
5. その前に... LARAVELの認証 について
6. 認可? 　POLICY? 🧐
7. 前提知識 ユーザーが を実行する権限を持っている かどうかを判断 認可とは？ 01 に対する認可を管理 Policyとは？ 02 特定のアクション 特定のモデル
8. Policyの紹介 Policyは　　　　　　　　　に対する認可を管理できる 特定のモデル
9. Policyの紹介 Policyは　　　　　　　　　に対する認可を管理できる 特定のモデル
10. Policyの紹介 Policyは　　　　　　　　　に対する認可を管理できる 特定のモデル （リクエスト元の）ユーザ自分自身のみがユーザを閲覧できる
11. 2. Laravel認可の　　 基本
12. 2. Laravel認可の基本 Gateファサード経由 の認可 routingに書く Middleware の認可
13. 2. Laravel認可の基本 Gateファサード経由 の認可 routingに書く Middleware の認可
14. routingに書く Middlewareの認可 Laravelでは特定のユーザだけがアクセスできるように設定を Routingに直接記載できる
15. Laravelでは特定のユーザだけがアクセスできるように設定を Routingに直接記載できる routingに書く Middlewareの認可
16. Laravelでは特定のユーザだけがアクセスできるように設定を Routingに直接記載できる 認証済みの人のみアクセスできる routingに書く Middlewareの認可
17. 2. Laravel認可の基本 Gateファサード経由 の認可 routingに書く Middleware の認可
18. Gateファサード経由 の認可 簡単に　　　　　　の認可ロジックを定義できます。 カスタム
19. Gateファサード経由 の認可 簡単に　　　　　　の認可ロジックを定義できます。 カスタム
20. 3. それぞれの メリット・デメリット
21. 3. それぞれのメリット・デメリット Gateファサード経由 の場合 routing記載 の場合
22. 3. それぞれのメリット・デメリット Gateファサード経由 の場合 routing記載 の場合
23. routingファイルに認可を書く 場合の問題点 routingファイルが複雑化 認可ロジックも含んでしまう デメリット routingに全部かいてある メリット
24. 3. それぞれのメリット・デメリット Gateファサード経由 の場合 routing記載 の場合
25. routingファイルに認可を書く 場合の問題点 定義した数だけ増える 管理が命名方法に依存 デメリット 認可ロジックがGate定義 に集中 メリット
26. じゃあ認可の責務がど こにあるべきか？
27. 凝集性を 高めるためには？
28. 認可ロジックは操作の近 くにあるといいかも
29. 前提知識 ユーザーが を実行する権限を持っている かどうかを判断 認可とは？ 01 に対する認可を管理 Policyとは？ 02 特定のアクション 特定のモデル
30. 4. 　　　　　　　　　　　を 使った認可の設計 ValueObject・Entity
31. 対象プロダクトについて レイヤードアーキテクチャ + DDD（一部アレンジ）
32. 対象プロダクトについて レイヤードアーキテクチャ + DDD（一部アレンジ） ValueObject・Entityが ドメインを表している (Service層・DomainService層が存在しない)
33. ドメインに対する操作 = ValueObject・Entityに対するそう
34. ここで認可のおさらい
35. 前提知識 に対する認可を管理 Policyとは？ 02 特定のアクション ユーザーが を実行する権限を持っている かどうかを判断 認可とは？ 01 特定のモデル
36. Entityごとに対する操作で 認可行う → Entityの凝集性が高まるのでは？
37. いつ認可を行うか
38. 対象プロダクトについて .2 ルーティングパラメータからEntityをbindしている GET: /{user}/profile UserEntityを取得し、ControllerへDI
39. 対象プロダクトについて .2 ルーティングパラメータからEntityをbindしている GET: /{user}/profile UserEntityを取得し、ControllerへDI このタイミングで認可
40. 5. まとめ
41. まとめ Entityごとに対する操作で認可行う Enittyの凝集性が高まる いつ認可を行うか bindingするタイミング？