слой? Что думаете?
Кейс из которого сделан вывод:
Поступил заказ на создание сайта – интернет магазина.
После поступил заказ на добавление возможности пользоваться магазином через телеграм бота
Что получается?
Бизнес логику магазина нам не нужно менять, нужно поменять только application слой (презентацию тут не учитываем, хотя её тоже надо новую писать)
Чтобы аутентифицировать пользователя нам надо как-то получить логин и пароль. В случай с сайтом это всё приходило одним post запросом. Телеграм боты же работают по другому, http протокол используется только в качестве транспорта, протокол общения с ботом же реализован посредством текстовых команд. Это что значит? Что тут по любому переписывать, чтобы сначала командой инициировать аутентификацию, дальше получить логин и затем пароль и только потом с этим что-то сделать
После того как мы получили логин и пароль и проверили существует ли юзер в нашем приложении, надо как-то установить сессию. Опять же тут сессия будет работать по другому, через id аккаунта, который приходит нам с каждым апдейтом от телеграм. Никаких кукисов тут нет, а значит переиспользовать логику сайта не получится. Значит переделываем
В итоге получается, что мы переделали всю аутентификацию при добавлении телеграм бота, а значит и переписали application слой. Если бы аутентификация была бы частью бизнес логики, то пришлось бы трогать её, что в итоге неправильно
Дальше Authorization
Можно ли было как-то переиспользовать Authorization логику при добавлении телеграм бота? Да, если бы проверки прав были бы в бизнес логике, то в телеграм боте нам пришлось бы только проверять выкинул ли бы бизнес слой авторизационную ошибку или нет.
Значит что? Authorization это часть бизнес слоя т.к. нам не нужно его переделывать при смене application слоя
Серебряные пули
А конкретнее? Ничего не понял
а какая разница как получать пароли? с текстового файла, с команды бота, с жисона или еще как-то? Хттп протокол это всегда трансопрт :D Сессия и без кук сессия.
Сори, но куча текста, а суть супер проста. Аутентифицировать пользователя прежде чем вызывать вызывать код, который от аутентификации зависит. Авторизация не простая штука и может быть реализована по разному. Например можно вообще ее убрать в отдельный ACL и проверять до или после бизнес кода
А что значит проверять после бизнес кода?
Ну например если бизнес код возвращает что-то что мы должны отфильтровать, но это редкие кейсы и они чаще решаются по-другому
Буллшит на постном масле. AAA может быть где угодно.
Обсуждают сегодня