Как делили модули в проекте

Что проверяют

Понимаете ли вы, ради чего дробится проект, и знаете ли, что даёт разделение помимо порядка в коде.

Как отвечать

Расскажите про принцип деления и цель. Основных схем две:

• по слоям (data, domain, ui): просто, но при работе над одной функцией приходится править все модули сразу, а сборка мало что выигрывает;
• по функциям (feature-jobs, feature-resume) плюс общие модули (core-network, core-ui, core-database): каждая команда работает в своём модуле, зависимости идут внутрь к общим.

На практике берут второе, а внутри модуля функции уже раскладывают по слоям.

Что даёт разделение:

• скорость сборки: Gradle пересобирает только изменившиеся модули и умеет собирать независимые параллельно;
• границы: модуль не может тянуть чужие внутренности, если они не вынесены в отдельный интерфейсный модуль. Разделение на api и impl позволяет зависеть от контракта, а не от реализации, и не пересобирать потребителей при правке реализации;
• тестируемость: модуль с доменной логикой не зависит от Android и тестируется обычными тестами на JVM;
• динамические компоненты: часть функций можно вынести в отдельно загружаемые модули.

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

Где спотыкаются

Дробят на десятки мелких модулей и получают сборку медленнее исходной из-за накладных расходов.

Заводят модуль common, куда попадает всё подряд, и он становится узлом, от которого зависят все.

Не разделяют контракт и реализацию, из-за чего правка одного модуля пересобирает половину проекта.