SP
Дополнительно куча профитов в плане тестирования и т.д. так как проверки доступов и сам юзкейс можно тестить независимо
Size: a a a
2021 July 20
SP
Что до "тупой разработчик забыл сделать проверки" - ну он может просто багов наделать, это уже вопросы к процессам и что бы система навязывала безопасные дефолты
SP
Есть исключения конечно но в общем и целом если соблюдать srp ocp и т.д. как то так и будет выходить
SP
Если от авторизации зависит "что можно менять" то это просто два разных юзкейса
HH
Но обычно частое требование помимо "отредактировать юзера … кого менять и чё менять" - еще важно кто меняет. И это обычно не относится к UI. Мб это через телеграм бота чел зашел, мб по http api или tcp
SP
Не, это можно изолировать и проверять выше.
NF
чет не понял мысль, юзкейс это актор-ассоциация-действие
NF
как он может не удовлетворять srp
SP
Ну тоесть обычно это не в тупую "if-ы в контроллерах" а там проверка сама тож куда то делигируется но
SP
Под "юзкейсом" в этом случае обычно подразумевается оркестрация - grasp контроллер такой
HH
А какой смысл делать это на уровне UI? Типа на тот случай если вдруг от типа UI будет зависеть правила авторизации?
SP
Use case example using a simplified version of Durán's template ...
NF
не ну я знаю что такое апп сервис/юзкейс это то же что и реализация команды в cqrs
SP
Мол вот такая байда в виде линейного сценария в коде
NF
и у неё/него всегда конкретный актор
SP
Ну это как "персона", это не всегда красиво на rbac мэпится
SP
+ а чё если у тебя мульти тенант
NF
нуу, ладно, возможно не всегда, но это такое
SP
А, я понял о чём ты. Ну в целом да
NF
неидеальный мир просто