если у вас огромная логика, которая касается кейсов - тогда у вас будет огромный кейс, зачем её пихать в презентацию ? если конечно в презенторе на каждый кейс нет "отдельной презентации", незнаю как заменить слово логика)

У меня во вьюхе просто отдельные кнопочки с надписями/значками "сделать это" или "сделать то-то". Каждая кнопочка отдает команду юзкейсу своему на выполнение. Юзкейсов много, команд много. Элементы, с которыми работают юзкейсы, выделяются одинаково - значит и в юзкейсы они попадают одинаково

И вот этому презентеру нужно эти юзкейсы передать. Зачем мне делать один огромный юзкейс, и в нем дописывать каждый раз новый функционал? Как я его свяжу с нажатием кнопки новой функции?

по моему мнению проблема именно в архитектуре)) вам нужно всего то обработать сложное состояние - и это уже не очень умещается во всякие там слои презентации и клина. У меня недавно была похожая ситуация, альбом с 9 фотографиями, которые соответственно могут находиться в разных состояниях, эти состояния нужно отображать, и есть логика "юзкейса" по добавлению/уделинию перемещению, всё как у вас. Но я сразу начал делать MVI, у меня было состояние фрагмента, в нём List<Photo>, каждое фото иммутабельно, содержит внутри своё сложное состояние, если нужно изменить лист - вызываю не презентор+юзкейс, а статическую функцию для List<Photo>.doSomething() , она корректно меняет это состояние, сетит его, и оно отображается. Всё как у вас, тогда не огромный презентор/юзкейс а просто файл ютилс с кучей  List<Photo>.doSomething()

Да тут не в том как данные энкодятся проблема, кмк, проблема в сегрегации

или отсутствии таковой

вообще не очень смысла вижу во всей этой дискуссии, когда 2/3 человек не понимают, как это вообще выглядит

окей, благодарю за терпение 👍

человека смущает что его состояние обрабатывается не парочкой юзкейсов, как в учебнике по клину, а, цитирую "огромным классом" или листом кейсов с id,  и хорошего решения тут не получится.

а огромный класс из домейн слоя пишется исходя из знаний о презентейшн слое?

ничего подобного

Очень нравится как вы сделали вывод, не видев ни строчки кода

а как иначе? если большой класс с набором методов - фасад из маленьких юзкейсов?

значит эти методы объединяются по какому-то принципу

Я тоже с подозрением отношусь к тому, что тут описывает Дамир, но я не понимаю, как тут можно вынести вердикт по тому, что делать и уж тем более пытаться пересадить человека на MVI, не зная, как выглядят юзкейсы, как, зачем и когда они комбинируются и так далее

ну да, очень близко к истине, но поправка - я хочу выполнение каждого кейса завязать на кнопку, применяю в качестве презентационного слоя MVP

ну ребята, давайте дискуссию не будем накалять, я понимаю, костыльное решение, но я спросил именно в том ключе, что самое костыльное в нём?

Да вот сложно понять по описанию

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

Ну хорошо. Задача получается выглядит так - есть некоторый большой стейт, который месится дёргаеньем юзкейсов, которые вызываются по нажатию на кнопки?