Граница между Service и UseCase действительно условна. Но цель UseCase не в строгой классификации классов. Его задача сделать структуру приложения отражением бизнес-сценариев системы.
Вы можете вынести общую логику в сервис, и сервис уже подключить в двух UseCase. Использовать один UseCase в другом UseCase лучше в самую последнюю очередь.
Маленькие сервисы это не UseCase. Размер класса не определяет его роль. UseCase - это один конкретный бизнес процесс, бизнес сценарий. А Service это переиспользуемая бизнес-логика, т.е. часть какого-либо сценария.
Понял, да конечно каждый подход надо обсуждать с командой, нужен/устраивает ли он команде/у. За-то вы знаете что умеет делать ваше приложение, могу вас обрадовать)
Когда мы ничего не возвращаем наша архитектура становится похожа больше на команды CQRS паттерн.
Но даже самые смелые возвращают id записи чтобы была возможность у фронта обратиться за получением, либо прибегают к использованию websocket чтобы получить тот или инное событие системы.
Большое спасибо что прочитали статью!)
Полностью с вами согласен, за нас уже всё придумали)
😂😂😂
Большое спасибо)
Большое спасибо что прочитали статью)
Обязательно почитаю про данный подход, спасибо!)
Спасибо, обязательно посмотрю!
Граница между Service и UseCase действительно условна. Но цель UseCase не в строгой классификации классов. Его задача сделать структуру приложения отражением бизнес-сценариев системы.
Большое спасибо что прочитали статью!)
Вы можете вынести общую логику в сервис, и сервис уже подключить в двух UseCase. Использовать один UseCase в другом UseCase лучше в самую последнюю очередь.
Маленькие сервисы это не UseCase. Размер класса не определяет его роль. UseCase - это один конкретный бизнес процесс, бизнес сценарий. А Service это переиспользуемая бизнес-логика, т.е. часть какого-либо сценария.
Полностью с вами согласен!
Понял, да конечно каждый подход надо обсуждать с командой, нужен/устраивает ли он команде/у. За-то вы знаете что умеет делать ваше приложение, могу вас обрадовать)
Согласен с вами полностью!
Когда мы ничего не возвращаем наша архитектура становится похожа больше на команды CQRS паттерн.
Но даже самые смелые возвращают id записи чтобы была возможность у фронта обратиться за получением, либо прибегают к использованию websocket чтобы получить тот или инное событие системы.
Большое спасибо что прочитали статью)
Если не секрет что конкретно разгребаете? С какими проблемами столкнулись?
Большое спасибо что прочитали статью)
Не могу отрицать такие реализации тоже имеют место быть, но в данном случае мы работаем с restAPI приходиться что-то возвращать)
Большое спасибо что прочитали)
Да UseCase-ы как оказалось уже стандарт, особенно их ценят в бигтех, так как бизнес-процессы там большие и запутаться в них легко.
Большое спасибо за прочтение и за ваш комментарий!
Остальные классы вы также можете протестировать)
Да контроллер может сохранить заказ без проблем!
Все мы учимся!
Спасибо что прочитали🤝🤝
Спасибо что прочитали)
Большое спасибо за обзор) Оч интересно было читать)
После твоего рассказа чувствую себя тупеньким)