Кого куда зачем делить, нормально же общались((

Чем крупнее и сложнее приложение, и чем больше над ним работает команд и разработчиков разного уровня, тем важнее уметь изолировать части кода друг от друга, и тем важнее становится скорость сборки приложения.

Если у вас 2 разработчика, то увеличение скорости сборки на 5 минут будет выигрывать компании пару часов в день, а если у вас 50 разработчиков – то у компании дневной КПД вырастет в несколько раз. Stonks! 📈

С этим и помогает многомодульность (если правильно организована🌚). Задумка такая: делим приложение на несколько мелких независимых частей, и тогда изменения в одной части не потребуют пересборки всего проекта для запуска – потребуется пересобрать только изменённую часть и её зависимости. Так мы и время сэкономим, и сможем отдать какую-нибудь новую часть новому джуну, не боясь, что он в процессе разработки пол-проекта нам поменяет. Пусть сидит там чудит себе на здоровье, на код-ревью посмотрим 😎

Есть два способа деления:
– по слоям Clean-архитектуры (модули app, domain, data и presentation)
– core-feature деление.

С первым всё понятно: тут главное удобство в том, что ты учишься жить по клину, и прям на уровне модулей можешь прописать, что в domain нельзя тащить android-классы, и что domain не зависит от остальных модулей-слоёв. Удобно для начинающих и для тренировки, но в плане масштабирования не очень удобная история: в какой-то момент вам захочется делить на более мелкие части, чем 4 модуля, захочется выносить отдельные фичи в отдельные модули, и приложение начнёт постепенно превращаться в кавардак.

Core-feature деление – более удобная история: в core пихаем всё общее и используемое всеми модулями, а в feature... Тут опять 2 варианта:
– либо один экран – одна feature, либо один флоу – одна feature. Флоу – группа экранов, объединённых общим смыслом – например флоу авторизации или флоу покупки. Чаще всего делят по флоу.

И внутри каждая feature живёт своей жизнью: если там нет работы с данными, а только презентейшн-логика, то там из клин-слоёв только presentation, а если есть и работа с данными, и своя бизнес-логика – то в feature будут все 3 своих clean-слоя. Под каждый слой своя папка внутри фичи.

Во "взрослом" core-feature делении к feature-модулю, в котором лежит вся логика фичи, делают ещё feature-api модуль – это модуль-прослойка, состоящий только из интерфейса модуля, отражающего то, что от этого модуля нужно всем остальным. Если модуль состоит из одной активити и всей сопутствующей логики – значит, скорее всего, апи фичи будет состоять из старта этой активити. И все остальные модули не будут ничего знать о том, что происходит в самой фиче – а будут только использовать апи этой фичи.

Звучит всё это заманчиво, но на деле и в реальной компании вас все равно ждёт кавардак, это я вам обещаю. У вас точно часть общего будет в core, часть в каком-нибудь "временном" common, а часть вообще "временно" рассована по отдельным фичам с задачей по рефакторингу в бэклоге, которую однажды вечером пятницы наконец закэнселят и примут неизбежную бренность бытия.

Готов поспорить, что ни у кого не найдётся идеального мультимодульного проекта в проде, и чтоб у него было хотя бы тыщ 50 активных юзеров 😏