17 | UseCase: куда класть бизнес‑логику, как строить кейсы и хэндлеры правильно

Обсуждаем практический подход к размещению бизнес‑логики через UseCase (ю‑кейсы). Разберём: зачем нужны кейсы, как отделять запросы/репозитории/валидаторы, почему не стоит завязывать кейс на Request/Response или статические фасады, как тестировать и подменять зависимости, роль хендлеров и сервисного слоя, типичные ошибки и антипаттерны в контроллерах и сервисах. Полезно для разработчиков, стремящихся к читаемой, тестируемой и расширяемой архитектуре. Таймкоды:  00:00:03 — Введение: место бизнес‑логики в приложении 00:02:05 — Баланс требований клиента и разработчика 00:03:48 — Функциональные требования и идея ю‑кейсов 00:05:31 — Ошибки при переносе логики в сервисный слой 00:07:23 — Рекомендации по чтению: книги по дизайну 00:10:06 — Доступ к литературе и практическое обучение 00:11:42 — Чего не должно быть в UseCase: получение данных из БД 00:12:32 — Адаптация кейсов к разным фреймворкам (адаптеры) 00:13:28 — Использование кейсов в консоли и отсутствие сессий 00:15:19 — Совместимость кейсов в разных контекстах (UI, консоль, тесты) 00:16:09 — Возврат результатов и обработка ошибок (исключения) 00:17:02 — Не принимать «сырой» массив — использовать объект формы 00:18:00 — Обработка ошибок через объект формы 00:18:55 — Пример в Laravel: контроллер, UserRequest, UserForm 00:19:52 — Зависимости UseCase: репозиторий, хешер, клиент уведомлений 00:21:47 — Создание пользователя: сущность, хэш пароля, уведомление 00:22:43 — Повтор ключевых моментов MVC и UseCase 00:24:34...