階層化アプリケーションの承認ルールはどこに適用されますか？

この質問は、私を混乱させる私の申請の規則を適用することについてです。

コントローラはサービスを使用しており、サービスはリポジトリを使用しています。

public class CommentController: ApiController{

    [HttpPost]
    public bool EditComment(Comment comment){
        commentService.Update(comment);
    }
}

public class CommentService{
    ICommentRepository repository;
    ....
    ....
    public void Update(Comment comment){
        repository.Update(comment);
    }
}

ユーザーが認証されると、コメントを更新できます。

• ただし、ユーザーは自分のコメントを編集する必要があります。

• ただし、管理者はすべてのコメントを編集できます。

• ただし、指定した日付以降はコメントを編集できません。

• 部門で編集

そして、私はこれらのルールのようなものを持っています。

サービスレイヤーで「ユーザー編集独自のコメント」ルールを適用すると、Update methotを変更し、コントローラーのパラメーターUser.Identity.Nameを渡します。

public class CommentService{
    ICommentRepository repository;
    ....
    ....
    public void Update(string updatedByThisUser, Comment comment){
        // if updatedByThisUser is owner of comment
        repository.Update(comment);
    }
}

しかし、本当のサービスオペレーションの変更はルールによるのでしょうか。

ルールをどこに適用できるかについて少し混乱しています。コントローラー、稼働中、またはリポジトリー内。

デザインパターンのようにこれを行う標準的な方法はありますか？

私は...するだろう

• 次のようなメソッドを実装する別のPermissionServiceを作成します isUserAllowedTo(user, PermissionService.Permissiontype.Update, PermissionService.Topic.COMMENT, additionalContextRelevantParameters)
• PermissionServiceコントローラでメソッドを呼び出します。必要なコンテキスト情報（セッションから）が利用可能です。

CommentServiceで許可サービスを呼び出すようにアーキテクチャを設計できます。ただし、これによりサービス（つまりセッション）に追加の依存関係が追加され、サービスの単体テストがはるかに困難になるため、これはお勧めしません。

まず、コメントサービスが実際に何を担当するかを検討するために、少し時間をかけてください。これはあなたの特定の要件、そしておそらくあなた自身の最良の判断に依存します。

コメントサービスの責任が特定のコメントの更新に限定されている場合は、あなたが書いた内容が適切です。この場合、特定のコメントを更新できるかどうかを確認するために、他のいくつかの条件付きロジックを検討する必要があります。おそらくコントローラーでこれを行うか、ユーザーがコメントを投稿できるかどうかを確認するために別のサブシステムを作成することができます。コメントサービスの再利用を計画しているのと同じように、これを再利用できます。

コメントサービスがユーザーのコメントの更新を担当する場合、サービスはUpdate（User user、Comment comment）になり、サービス内のビジネスルールを柔軟にチェックできます。

設計意図が明確になったので、ソリューションの実装方法が明確になります。