Сколько модулей было в проекте

Ну вот, смотри, как обычно бывает. Ты начинаешь проект, думаешь: "Да хуй с ним, один модуль app и хватит, зачем эти танцы с бубном". А потом проект растёт, как на дрожжах, и в какой-то момент понимаешь, что в одном-то модуле уже овердохуища всего намешано — и сетевые запросы, и база данных, и какая-то своя, блядовитая, бизнес-логика. И найти что-то — это тот ещё квест, ёпта.

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

Обычно в приличном Android-проекте можно встретить вот такой стандартный набор:

• app — это главный, основной модуль. Тут твой MainActivity живёт и вся презентационная хуйня.
• data — это, как не трудно догадаться, для данных. Тут твои репозитории, которые бздят в сеть или в локальную базу.
• domain — святое место для бизнес-логики. UseCase-ы, модели — всё, что должно работать без оглядки на то, Android это или нет.
• features — а вот это уже для хитрых жоп, которые юзают Clean Architecture. Каждая фича — свой модуль, типа :feature-auth или :feature-profile. Красиво, но возни дохуя.
• core — свалка для всего общего. DI-модули, утилиты, расширения для String — всё, что впендюривают куда попало.

Вот как это примерно выглядит в settings.gradle или settings.gradle.kts:

include ':app', ':data', ':domain', ':core', ':feature-auth'

Если по-простому, то в среднем проект таскает на себе 3–5 модулей. Но если это какой-нибудь монстр, типа приложения банка, то там их запросто может быть 10+, и каждый отвечает за свою залупу конскую. Главное — не переборщить, а то вместо архитектуры получится мартышлюшка с кучей зависимостей, которые только вздрачивают время сборки.