Вряд ли кто то мне ответит в пятницу вечером. Но тем не менее. Как думаете насколько корректно располагать часть бизнес логики в контроллерах и джобах с точки зрения хорошего дизайна и тестов? Просто сейчас фреймворки всё берут на себя, не нужно наследоваться от каких то интерфейсов, просто повесил анотацию и вот тебе контроллер или джоба. Или не нужно как то мапить данные в большинтсве случаев. И контроллеры или джобы получаются "пустыми", просто делегируя работу бизнес логике в сервисах(менеджерах, хэндлерах и т.п.).

Вряд ли кто то мне ответит в пятницу вечером. Но тем не менее. Как думаете насколько корректно располагать часть бизнес логики в контроллерах и джобах с точки зрения хорошего дизайна и тестов? Просто сейчас фреймворки всё берут на себя, не нужно наследоваться от каких то интерфейсов, просто повесил анотацию и вот тебе контроллер или джоба. Или не нужно как то мапить данные в большинтсве случаев. И контроллеры или джобы получаются "пустыми", просто делегируя работу бизнес логике в сервисах(менеджерах, хэндлерах и т.п.).

Вряд ли кто то мне ответит в пятницу вечером. Но тем не менее. Как думаете насколько корректно располагать часть бизнес логики в контроллерах и джобах с точки зрения хорошего дизайна и тестов? Просто сейчас фреймворки всё берут на себя, не нужно наследоваться от каких то интерфейсов, просто повесил анотацию и вот тебе контроллер или джоба. Или не нужно как то мапить данные в большинтсве случаев. И контроллеры или джобы получаются "пустыми", просто делегируя работу бизнес логике в сервисах(менеджерах, хэндлерах и т.п.).

Смотря что такое бизнес-логика. Имхо этот вопрос улетучивается если понимать SRP и остальные OOD приципы, про направление к стабильности в зависимостях и абстракции

Я не хочу класть в контроллеры детали реализации бизнес логики. Но допустим выбрать какой то список по статусам и применить к ним какое то действие. По идее это бизес логика, т.к. только она должна знать что то про статусы сущностей

Я не хочу класть в контроллеры детали реализации бизнес логики. Но допустим выбрать какой то список по статусам и применить к ним какое то действие. По идее это бизес логика, т.к. только она должна знать что то про статусы сущностей

Нужно понимать, что это все про изменения. Если ты напишешь код и не будешь его менять то можно городить все где хочешь

Вряд ли кто то мне ответит в пятницу вечером. Но тем не менее. Как думаете насколько корректно располагать часть бизнес логики в контроллерах и джобах с точки зрения хорошего дизайна и тестов? Просто сейчас фреймворки всё берут на себя, не нужно наследоваться от каких то интерфейсов, просто повесил анотацию и вот тебе контроллер или джоба. Или не нужно как то мапить данные в большинтсве случаев. И контроллеры или джобы получаются "пустыми", просто делегируя работу бизнес логике в сервисах(менеджерах, хэндлерах и т.п.).

Да, я понимаю что всё дело в конкретном случае и в "предрасположенности" кода к изменениям в будущем. Просто не могу сформировать для себя границы, поэтому и спросил. Но ты прав, нельзя об этом говорить абстрактно

Иногда скорость разработки важнее чем будущая поддержка, мб этот код вообще нах никому не нужен будет и его выбросят. В старапах всяких это частая тема, пользователям фича не зашла - выбросили, а ты там архитектуру городил и 500 лет думал куда класть в контроллер или бизнес-сервис, хотя мог сразу одну функцию напистаь

Мб если у тебя нет ответов то и не стоит заморачиваться, лепи в спринговских контроллерах. Сделай "ленивое" изменение кода, когда понадобится поменять и разделить ты поймешь и поделишь на два модуля)

Что значит ленивое изменение?

Это вопрос не про конкретный сервис(продукт). А скорее для меня, чтобы выработать некоторые шаблоны разработки и пользоваться ими, потому что они точно дадут мне архитектуру, которая не превратится в непонятную лапшу

Сильно заявление. Шаблоны опасная вещь. Я как то на другую работу перешел и стал там такое лепить, а их предметная область вообще на это не ложилась и проблемы были другие и "шаблон" мой не подходил, я понял это только через 2 недели когда все превратилось в лютую дичь