В последнее время все как с ума посходили по поводу чистой архитектуры. Носятся с ней как с писаной торбой. Думают: «Вот мы сейчас разделим проект на кучу модулей, и будет классно и удобно».

Только вот это ловушка! Разделение по модулям без необходимости создаст кучу проблем.

Во-первых, замедляется сборка проекта. Во-вторых, тратится много времени на разбор кода. В-третьих, затрудняется отладка вплоть до невозможности.

Зачем делать абстракцию для базы данных, когда в большинстве случаев используется SQLite, а обертки для нее вроде Room? База данных - это деталь, пишет дядюшка Боб. Я же с ним не согласен: база данных - это компонент. Особенно в контексте мобильных приложений.

Зачем городить абстракции для работы с сетью? В большинстве случаев она не требуется, так как у нас одно API и один сервер. Не обязательно разделять репозиторий кэша и сети. Создаются три класса: один отвечает за репозиторий (Repository), другой за сеть (Network), третий за кэш (Cache). Repository сначала опрашивает Cache, получает результат и возвращает его приложению. Если данных нет, опрашивает Network, сохраняет результат в Cache и возвращает его приложению. Иными словами, Repository - это оркестратор.

Разделять по модулям вообще не нужно. Достаточно разделить по пакетам:

com.app ├── ui │ ├── screens (Composables / Activities / Fragments) │ ├── components (UI widgets) │ └── theme (Styles) └── logic ├── models (DTO, Entities, Domain Objects) ├──viewModels (StateFlow, бизнес-логика) ├──repository (Оркестратор: сеть + БД) ├── db (Room DAO, Entities) └── network (Retrofit clients, Interceptors)

Кто-то станет возражать: «А если команда большая, на один проект?» Я же скажу: на одно мобильное приложение должно быть не более 1–2 человек. Если больше - значит, что-то пошло не так, и все будут друг другу мешать, сколько бы ни делили несчастный проект на модули.

Даже если проект действительно очень большой и прям просит разделения на модули, то тут на помощь приходит не Gradle, а Git и Git Flow!

В эпоху ИИ-агентов и мощных IDE этот подход более универсален и соответствует духу времени. Сама же чистая архитектура в своем каноничном виде не годится для мобильной разработки.

Резюме: Чистая архитектура в виде кучи Gradle-модулей - это оверинжиниринг для 90% проектов. Правильный подход: 1. Делим код на пакеты по ответственности (UI, Logic). 2. Если пакет становится общим для других проектов - выносим его в отдельную библиотеку (Jar/Aar). 3. Git Flow как основной инструмент координации работы команды.