DDDにおける認可の扱いとKotlinにおける実装パターン / authorization-for-ddd-and-kotlin-implement-pattern

Transcript

1. 1 ©2024 Loglass Inc. DDDにおける認可の扱いと Kotlinでの実装パターン 2024.7.18 Server-side Kotlin Night Yuta Muramoto / Loglass, Inc.
2. 2 2 ©2024 Loglass Inc. 株式会社ログラス 開発部 エンジニア 村本 雄太 / Yuta Muramoto (@urmot2) 自己紹介 株式会社ログラスでLoglass⼈員計画という新規プロダクトの開発をし ています。 普段はKotlin + SpringBootで開発しており、Kotlin Festでは「認可 x DDD」という内容でプロポーザルを出したが、お⾒送りになったの で、今回リベンジさせてもらいます。
4. 4 ©2024 Loglass Inc. 認可について
5. 5 ©2024 Loglass Inc. 5 認可について 認可は操作を実行する許可を出すため仕組み 例： ブログ投稿サービス 
 • 権限(Permission): 投稿者はポストを編集できる。 
 • 認可(Authorization): ユーザーがポストを編集する権限があれば許可し、なければ拒否する。 

6. 6 ©2024 Loglass Inc. 6 認可について よくあるパターン
7. 7 ©2024 Loglass Inc. 7 認可について 認可処理はどのように書くべき？ • よくあるパターンで書く？ 
 • ライブラリを利用する？ 
 • DDDを採用している場合は？ 
 • マイクロサービスではどうあるべき？ 

8. 8 ©2024 Loglass Inc. 8 認可について 認可処理はどのように書くべき？ • よくあるパターンで書く？ 
 • ライブラリを利用する？ 
 • DDDを採用している場合は？ 
 • マイクロサービスではどうあるべき？ 

9. 9 ©2024 Loglass Inc. DDDにおける認可について
10. 10 ©2024 Loglass Inc. DDDにおける認可について 実践ドメイン駆動設計が認可についてしっかり書かれていた
11. 11 11 ©2024 Loglass Inc. しかし彼らはモデルには明確な制限があって、それ以上に広げ すぎては行けないということを理解していなかった。その結果、 セキュリティや権限の情報をコラボレーションモデルに組み込 んでしまうという、間違いを犯してしまった。 (中略)
 つまりそれは、二つのモデルをひとつに混ぜ込んでしまうという ことだ。程なく彼らも気がついた。この混乱する状況は、セキュリ ティについての関心事をコアドメインに混ぜ込んだことに起因す るものである。まさに コアビジネスロジックのど真ん中で、開発 者がクライアントの権限をチェックしてからリクエストを処理し ていたのだ。
 
 by 実践ドメイン駆動設計 第2章「ドメイン、サブドメイン、境界づ けられたコンテキスト」 
 DDDにおける認可について
12. 12 12 ©2024 Loglass Inc. DDDにおける認可について
13. 13 13 ©2024 Loglass Inc. DDDにおける認可について
14. 14 ©2024 Loglass Inc. 14 DDDにおける認可について 最終的に認可に関する関心事をコアドメインから分離している
15. 15 ©2024 Loglass Inc. 認可のベストプラクティスでは？
16. 16 ©2024 Loglass Inc. 認可のベストプラクティスでは？
17. 17 17 ©2024 Loglass Inc. 認可のベストプラクティスでは？ 承認はすべてのアプリケーションにとって重要な要素ですが、ユーザー にはほとんど見えません。 
 また、通常はコア機能やビジネスロジックとは無関係です 。
 https://www.osohq.com/academy/what-is-authorization 

18. 18 18 ©2024 Loglass Inc. 認可のベストプラクティスでは？ 承認はすべてのアプリケーションにとって重要な要素ですが、ユーザー にはほとんど見えません。 
 また、通常はコア機能やビジネスロジックとは無関係です 。
 https://www.osohq.com/academy/what-is-authorization 
 上記にはさまざまな順列や組み合わせがありますが、ほとんどのアプ リケーションでは通常、次の設定をお勧めします。 
 
 1. 認証を処理するには、ID プロバイダーを使用します。 
 2. アプリケーション自体で認証を強制します。 
 3. 承認インターフェースを追加して、 承認ロジックをアプリケーショ ンコードから分離します。 
 https://www.osohq.com/academy/what-is-authorization 

19. 19 ©2024 Loglass Inc. Kotlinで認可ロジックを分離する方法
20. 20 ©2024 Loglass Inc. 20 認可について 認可処理はどのように書くべき？ • よくあるパターンで書く？ 
 • ライブラリを利用する？ 
 • DDDを採用している場合は？ 
 • マイクロサービスではどうあるべき？ 

21. 21 21 ©2024 Loglass Inc. Kotlinで認可ロジックを分離する方法 例: ブログ管理サービス ブログ管理サービスの認可ロジックは以下の通りです。 
 • チーム内にブログを投稿できるのはチームメンバーのみ 
 • プライベートな記事はチームのメンバーだけが閲覧可能 

22. 22 22 ©2024 Loglass Inc. Kotlinで認可ロジックを分離する方法 1. 共通interfaceを使うパターン
23. 23 23 ©2024 Loglass Inc. Kotlinで認可ロジックを分離する方法 共通interfaceを使うパターン
24. 24 24 ©2024 Loglass Inc. Kotlinで認可ロジックを分離する方法 1. 共通interfaceの実装
25. 25 25 ©2024 Loglass Inc. Kotlinで認可ロジックを分離する方法 1. 共通interfaceを使うUseCase
26. 26 26 ©2024 Loglass Inc. Kotlinで認可ロジックを分離する方法 利点: ドメインロジックに認可ロジックが入りこまない (分離できる )
27. 27 ©2024 Loglass Inc. Kotlinで認可ロジックを分離する方法 欠点： 認可処理を強制できない
28. 28 ©2024 Loglass Inc. 28 Kotlinで認可ロジックを分離する方法 2. Authorizedモナドを利用するパターン
29. 29 ©2024 Loglass Inc. 29 Kotlinで認可ロジックを分離する方法 Authorized<T> は Authorizer 経由でしか作成できない
30. 30 ©2024 Loglass Inc. 30 Kotlinで認可ロジックを分離する方法 認可処理の実装は各コンテキストの packageに配置
31. 31 ©2024 Loglass Inc. 31 Kotlinで認可ロジックを分離する方法 Repositoryの引数を Allowed<T> にする
32. 32 ©2024 Loglass Inc. 32 Kotlinで認可ロジックを分離する方法 利点: 認可処理を実行しないと saveメソッドが呼び出せない！
33. 33 ©2024 Loglass Inc. まとめ
34. 34 34 ©2024 Loglass Inc. まとめ 認可ロジックはコアドメインから分離する！ • IDDD本でも、Oso Authorization Academyでも認可ロジックの分離を推奨しています 
 • 認可ロジックを分離する方法として以下を紹介しました 
 a. 共通interfaceパターン 
 b. Authorizedモナド
 • 認可ロジックは取得系のほうが考えることが多く難しいです 
 • Spring Securityなどのライブラリを利用することでうまく分離可能な場合もあります 
 • ユースケースやプロダクトの状況に合わせて最適な実装方法を選択する必要は依然としてある