Что такое бизнес-логика?

Что проверяют

Отличаете ли вы правила предметной области от кода, который обслуживает экран и фреймворк. За вопросом стоит слоистая архитектура: собеседующий хочет понять, где у вас окажется правило про лимит операции, в отдельном сценарии или в обработчике нажатия.

Как отвечать

Бизнес-логика это правила и операции, описывающие, что система делает по требованиям бизнеса, независимо от того, пришёл вызов с кнопки, из пуша или из фонового воркера. Расчёт стоимости, проверка допустимости перевода, переходы статуса заказа, начисление бонусов.

Не бизнес-логика: форматирование даты для экрана, показ уведомления, выбор между кэшем и сетью, преобразование ответа сервера в модель. Это логика представления и доступа к данным.

В Android раскладка обычная: слой domain с моделями и сценариями на чистом Kotlin без импортов из android, слой data с репозиториями и источниками, слой представления с ViewModel, которая хранит состояние и вызывает сценарии.

class CanWithdraw(private val limits: Limits) {
    operator fun invoke(balance: Money, amount: Money) =
        amount <= balance && amount <= limits.perOperation
}

Сильный ход назвать критерий самому: если класс с правилом нельзя покрыть обычным юнит-тестом без Robolectric и эмулятора, логика утекла во фреймворк.

Где спотыкаются

Называют бизнес-логикой всё, что не вёрстка, и в один мешок попадают кэш, повторы запросов и разбор ответа. После этого разговор про слои рассыпается.

Держат правила в ViewModel или прямо во фрагменте. Пока экран один, это терпимо; со вторым входом в ту же операцию правило копируют, и через релиз копии расходятся.

Тащат Context и ресурсы в domain ради текстов ошибок. Слой перестаёт быть переносимым и тестируемым, хотя подпись правильнее собирать на уровне представления по коду ошибки.