ドメインモデルの側面で役割ベースのアクセスロジックをどこに追加しますか？図書館管理システムの場合

Question

私が抱えている最大の困難は、システム内で私が特定した各オブジェクトの責任をどこに収容するかを見つけることです（問題空間など）。ライブラリ管理システムの機能の非常に簡略化した説明を投稿しています。

使用事例

1. 管理者として、私は本を在庫に追加したり、本の「状態」を任意の許容値に変更したりできます。
2. スタッフとして、本の「状態」を「返却」または「借用」にしか変更できません。
3. お客様として、「返品済み」または「借用済み」の状態のすべての本を表示できます。
4. ブックの状態は、「返却済み」、「借用済み」、「削除済み」、
5. 管理者として、私はスタッフに本を追加するためのアクセスをスタッフに許可または取り消すことができます

エンティティ

1. ユーザー
2. ユーザーリポジトリ
3. 本
4. 書籍リポジトリ
5. 図書館
6. 許可

協会

ライブラリはユーザーリポジトリとブックリポジトリを1対1の関係で保持し、リポジトリは対応するエンティティを1対多の関係で保持します。

動作

1. ユーザーリポジトリ：

   • すべてのユーザー/問題のドメインに関連する関心のあるユーザーのリストを取得します。
   • ユーザーエンティティを外部システム（データベースまたはクラウド）に保存します

2. ブックレポ：

   • ユースケースにそれぞれ対応するすべてのブック/関心のあるブックのリストを取得します。
   • Bookエンティティを外部システム（データベースまたはクラウド）に保存します
   • 本を追加

質問

1. ユースケース3および5の場合、アクセスベースのロジックを追加します。今回のケースでは、ユーザー（adminのみ）オブジェクトに、書籍を追加するためのアクセス権を付与または取り消すアクセス権があるかどうかを判断します。また、ユーザーの役割に基づいて返される書籍のリスト。

注：達成したい

• エンティティ間の結合
• 80〜90％のカバレッジで各モジュールのユニットテスト
• アプリケーションレイヤーの場合、現在または新しいチームメンバーがドメインオブジェクトを直接公開しないようにする方法

Answer 1

標準的な方法は、ビジネスロジックを作成するときにこれらの認証ルールをすべて無視し、その後、アプリケーションに標準のロールベースの認証システムを単に追加することだと思います。

たとえば、アプリがWebページである場合、スタッフ以外のユーザーが「本の状態を変更する」ページにアクセスするのを防ぐだけです。