Подскажите, кто делит модули по фичам, по каким критериям производиться

это разделение? к примеру есть есть такой список экранов:
- авторизация
- регистрация
- добавление товара
- просмотр информации о товаре
- просмотр списка товаров
- профиль

логично выделить модуль (авторизация, регистрация) и модуль (добавление товара, просмотр информации о товаре). а что делать с остальным? делать отдельные модули для каждого экрана или скидывать их в какой то один модуль "other"?

Делите логически и по сущностям, с которыми работаете. +можно подумать о переиспользуемости

а вам модули для чего? Несколько приложений, или ускорение сборки, или просто для красоты?

пока для сборки, в скором будущем буду работать над переиспользованием

Т.е. Для общего развития?

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

Фича api, фича api-impl, фича ui

ну можно и так сказать, хочу выработать правильное понимание этой темы чтоб потом не переписывать сто раз проект

Фича-ui? Что-то новенькое

Я вас наверное растрою, сказав, что переписывать все равно придётся

нуу, наверное)

Вполне себе. Живой пример из моего текущего проекта. Создание поста в соц сети. Фича поделена на 2 части - логика и ui. UI - типа wizard'a наполняет логику данными, потом UI закрывается, а логика в фоне работает - обрабатывает медиа, постит и т.п.

А что-то не так? Или вы юай для фичи не делаете? Иль назвал не по стандартам?

я выделяю только 2 типа фичей: api и impl. Не знаю какая 3я может быть. Хотя если для Вас feature-api == feature-data - тогда все понятно

Позиция понятна

что у Вас находится в feature-api?

Если вопрос идет о проектных Gradle модулях, то не рекомендую этого делать в целях достижения скорости сборки проекта, так как поддержка разных модулей (обслуживание скриптов, контроль иерархии модулей…) и их агрегация (ведь они не могут работать по отдельности?) будет стоить дорого в процессе разработки (особенно, чем их больше). Текущие средства сборки хорошо справляются с инкрементной сборкой проектов, поэтому лично у меня не возникает проблем на большом проекте с его времени сборки. Лучше всего использовать отдельные Gradle модули, когда жизнь вынуждает к этому. К примеру, теперь логика аутентификации являются переиспользуемой для несколькоих проектов и может использоваться как артефакт, который собирается отдельно. Или не логика, а набор UI компонентов, который определяет стиль приложения. Конкретно экраны я отношу к логике отображения (presentation), что является неотъемлемой частью самого приложения, поэтому их не стоит выносить извне куда-то. Стоит помнить, что усложнение архитектуры еще больше ведет к усложнению поддержки и эксплуатации, нужно будет решить проблемы сборки экранов приложением, поддержка документации обо всех решениях, связанным с тем, как теперь работать с этими модулями. То есть выгода должна быть больше от всех усложнений.

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

Согласен. Каждый случай необходимо рассматривать отдельно, не будет одного ответа как правильно делать. Вопрос был про организацию модулей по экранам. Я думаю, что будет эффективней держать все в рамках одного модуля, который объединяет их логику работы в одно отображение