Представь себе что система которая выполняет юзкейс просто не имеет доступа к информации что бы произвести авторизацию. Микросервисы всякие. Когда тебе на вход просто эксес токен под конкретный ресурс и операцию приходит и все что остаётся это подпись проверить

ну это получается такой дженерик вариант, т.е. там же нет какого-то свич кейса по актору, а значит актор все ещё один, просто Actor<T> так скажем

ну т.е. это все ещё 1 актор, но мы слишком глупы чтобы дать ему нормальное явное имя

Да, это вопрос обобщения эктора для конкретной операции. Разные роли с разными уровнями доступа но представляющие одного эктора для этого юзкейса

Но в целом... Тот же трюк с эксес токенами будет и из нутри юзкейса работать. Главное что бы внутри небыло ветвлений, тогда срать на количество зависимостей

Почему тут все такое сложное , аааааа

Я так понял что юзкейс как вариант можно поделить на юзкейсы "ПользовательУдалиСебя", "МодераторУдалиПользователя", "АдминУдалиПользователя"? 😁

Ребятки, объясните плз одну штуку, я уже вопрос кидал, может сейчас повезёт

Многие проектировщики, и я в том числе, любят разносить бизнес-логику по двум категориям: логика домена (domain logic) имеет дело только с предметной областью как таковой (примером могут служить стратегии вычисления зачтенного дохода по контракту), а логика приложения (application logic) описывает сферу ответственности приложения [11] (скажем, уведомляет пользователей и сторонние приложения о протекании процесса вычисления доходов) - "Кусочек чужого текста"

То есть, если вычисление не должно в чистом виде отдаваться на слой presentation, то мы должны его прокинуть в domain layer, а если вычисление и есть то, что мы хотим увидеть на контроллере, то можно и в application layer(service) закинуть, так, правильно понял?

нуу, нет скорее "УдаляльщикПользователейУдалиПользователя" если там нет разной логики под каждую из других ролей, но обычно мы не вводим настолько конкретные роли явно, а просто проверяем пермишн
(хотя иногда мы хотим иметь МенеджераПользователей в явном виде, но это сильно зависит от домена)

Ну разве что ради шутки) Смысл если они делают одно и тоже?
Я не вижу минусов в том, чтобы вызывать проверку внутри так называемого usecase.

Похоже на ту тему где спорят про validate vs parse

дергать слои выше на прямую не страшно, а вот перемещать логику которая должна быть выше в нижележащий слой это уже попахивает

Понял, спасибо всем за помощь 🤝

Ну я понимаю, что домена можно дернуть контролёром и сервис тоже

Но тут именно мне не понятен момент где грант сервиса, а где домена

Я вообще не понимаю кто что и почему заносит

Сервис = логика приложения

Но есть прикладная логика к этой логике

Это и есть домен ?

Ну то есть у нас приложение, которое берет и формирует pdf карточки , ну или не pdf, не важно , отдача pdfКи стримом = application layer, а конвертация из html в pdf = domain?