Статья (EN,6м) с описанием тех моментов когда вам надо насторожиться, если в коде UseCase встречается это (добавил от автора статьи, себя и из комментариев под постом): 1️⃣Вы не понимаете зачем он вам нужен, а сделали потому что так написали в умной/статье книге или 2️⃣ Из названия классы UseCase не понять что он делает, либо делает не то что в названии 3️⃣ Код UseCase небезопасен для вызова с Main потока 4️⃣ Имеет в зависимостях платформенный код (например из Android SDK это может быть Context) 5️⃣Класс UseCase имеет больше одной публичной функции 6️⃣ UseCase имеет состояние (сохраняет данные в поля) 7️⃣ Метод UseCase содержит 1 строчку кода (например вызов метода из репозитория или БД) 8️⃣UseCase вызывает другой UseCase. Возможно стоит реорганизовать логику так чтобы вынести общий код в утилитные классы
В комментариях добавляйте свои красные флаги в работе с UseCase
· 13.07.2024
Пункт 7 разве не обычное дело? ))
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 14.07.2024
В целом необходимость юзкейсов должна быть связана с "толщиной" вашего клиента.
В идеале, если вам на этапе проектирование приложения (как целой системы, включая работу с бэком) удастся понять, будет ли у вас достаточно много логики на клиенте. Или это будет более тонкий клиент. И отсюда отталкиваться. Если тонкий клиент, то вообще норма пропустить этот слой. Вон, как гугл у себя пишет, что доменный слой "опциональный". Примерно так.
Но если вы все взвесили и юзкейсы вам нужны, то я придерживаюсь позиции, что использовать их везде. Даже если они у вас получаются на 1 строчку. Не вижу в этом ничего страшного.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён