Strategyパターンを用いてリポジトリに認可機能を持たせる
1. 目的
ドメインモデルの保存/削除時、認可処理を行いたい
- ドメインモデルを永続化する際、一般的にリポジトリを経由してDB（やファイル）に永続化を行う
- この時、データの操作権限が適切であるか認可処理を行いたい
2. 課題
ドメインモデルに認可ロジックを入れるのは微妙
- ドメインモデル自体に認可ロジックを持つのはドメインモデル自身の操作権限をでドメインモデルが管理するという点で悪くはない
- しかし、認可ロジックは複数のパターンが存在することが通例である
- 全ての認可パターンをドメインモデルに保持させる事はドメインモデルの本質的な責務が薄まってしまう恐れがあり、結論としてはあまり良くはない
ユースケース層に認可ロジックを実装するのは微妙
- ユースケース層ではドメインモデルを使ってユースケースを実行する
- このユースケース層に認可ロジックを組み込むことも考えられる
- しかし、各ユースケースに認可ロジックが散在することになるので、保守性の面で課題が残る
リポジトリに認可ロジックを実装するのは微妙
- 認可ロジックをドメインモデル本体に持たせるのは微妙、ユースケース層に持たせるのも微妙となれば、リポジトリにそれを持たせることが考えられる
- しかし、リポジトリに直接認可ロジックを記述する事は結局複数の認可パターンに対応することが難しいという問題を解決できない
3. 解決策
リポジトリの更新メソッドに認可ロジックを与える（Strategyパターン）
- つまるところ、真の要件は「認可ロジックとリポジトリを粗結合にしたい」「任意に認可ロジックを切り替えたい」であるので、認可ロジック自体をStrategyパターンとして実装すればよい
認可ロジックを関数化/クラス化してドメイン層に配置する
- 認可ロジック自体は関数オブジェクトなりクラスなりに実装し、ドメイン層に配置することになる
- リポジトリの更新メソッドを呼び出す際に認可ロジック自体をパラメータとして与え、リポジトリの更新処理内で認可ロジックを実行する
- これにより、「認可ロジックとリポジトリを粗結合にしたい」「任意に認可ロジックを切り替えたい」という要件が解決する
4. メリット
認可ロジックを切り替え可能になる
5. デメリット
構成要素が増える
6. 注意
- この設計ではリポジトリの利用者（プログラマ）が適切なチェックルールをリポジトリに渡すことが期待されている
- したがって、プログラマが誤って別のチェックルールを適用した場合は意図した結果が得られない
- また、正しいルールが適用されているかを機械的（または型チェック）に判断できない欠点がある
参考資料