Особая логика авторизации. Где эта логика должна находится и как это архитектурно организовать?
В системе есть множество ограничений (правил авторизации и валидации).
Логика, которая связанна с валидацией и обеспечением консистентности данных находится в сервисах с бизнес-логикой (Пример: дата начала должна быть меньше даты окончания, евенты не должны пересекаться по времени и т.п.).
Но еще есть ограничения доступа, которые выполняются не только на основе роли пользователя, а на основе определенных вычислений, состоянии данных в БД.
Есть некое расписание ивентов и след. логика авторизации:
- Если пользователь не админ и ивент имеет статус "Отменен" или "В подготовке", запретить редактирование. Иначе разрешить.
- Если пользователь не админ и ивент был проведен больше, чем месяц назад, запретить редактирование. Если пользователь - автор ивента, то разрешить.
Я не уверен, что будет правильно вплетать в сервисы с бизнес-логикой информацию о пользователях для подобных вычислений. К тому же было бы удобней выполнять эти проверки в контроллерах, что бы формировать правильные сообщения об ошибках, а не выбрасывать кучу эксепшенов из сервисов.
Хотелось бы разграничить ответственность (возложить задачу авторизации на какие то другие сервисы).
На данный момент, это обычные сервисы с суффиксом *PermissionResolver.
Возможно есть какие то проверенные практики для реализации такого функционала?
