/note/tech
MEMO(1):
- データの削除処理は往々にしてID（主キー）だけ指定して削除という実装になりがち（工数やメンテナンス性のバランス的に仕方ない）
- IDはintやstringであることが多いので、ドメインロジック（権限チェックや認可）を持てない
- チェックを書き忘れる・すり抜けて削除が実行される潜在的危険性がある
- という事で、DeletableIDという型を作り、IDをラップする
- リポジトリ層の削除処理はDeletableIDを受け取るようにする
- DeletableIDの生成処理をドメイン層だけで生成できるようにする
- 権限チェックや認可などのドメインロジックはDeletableIDが行うようにする
- ...する事で危険な削除処理を安全にすることができる
- よいアイデアだ
MEMO(2):
- 良いアイデアかと思ったけど、エンティティが自分を削除する権限の認可処理を持つのはドメインモデルとしてあるべき姿なのか？ という疑問が湧いた
- 権限や認可ロジックはそのドメインモデルが表現するべきドメイン知識と言えるのだろうか？
- ドメイン知識だと言えなくもないし、システム側の関心であるとも言えなくもない
- つまり、どっち付かずの概念である
- こういう場合は、判断ロジック自体を別モジュールに切り出した方が予後が良さそう
- 自分なら認可判断ロジックのクラスを作り、リポジトリが認可判断ロジックを呼び出すようにするだろうか
- データのCRUDは結局リポジトリの責務であり、その操作の権限・認可チェックはリポジトリでやるのが自然に思える
- 認可判断ロジックを独立させることで、認可判断ロジック自体のユニットテストも可能になる
(2023/12/14)