Разработчик, привет! В этом статье я хочу поделиться примером модульного андроид приложения с помощью NavComponent (JetPack) и Koin (DI). У нас в компании есть много разных андроид проектов, которые должны использовать фичи (Feature) друг друга - это некая экосистема. Чтобы этого добиться нам необходимо разрабатывать эти фичи максимально независимыми и гибкими. Требования к фичам можно сформулировать так: Фича должна иметь возможность подменить логику и UI независимо друг от друга. Для вызова фичи должно быть достаточно знать её интерфейс (метку) и необходимые параметры входа/выхода. Сама фича должна скрывать свою реализацию от других фич. Поддержка feature on-off из коробки. Для меня feature - это логически объединенная система компонентов, которая выполняет некоторую функцию в приложении. Например, авторизация, покупка. Фича содержит свой UI граф (цепочку фрагментов), который должен храниться в backStack навигации, а после выхода из фичи, возвращать пользователя в точку вызова фичи. Условная схема приложения из двух фич: На схеме приложение, в котором есть MainFragment (M) и две фичи (А и В). Из М можно перейти в фичи А и В. А из фичи В мы можем попасть в фичу А. Причем, после завершения фичи А мы должны вернуться в точку вызова: если мы попали в фичу А из M, то возвращаемся в М, а если вызывали фичу А из В, то в В. При этом стек навигации должен сохраняться. А1, А2, B1, B2 - фрагменты фич. Каждая фича состоит из трех физических модулей андроид проекта: API, BL, UI.   На рисунке стрелка указывает направление зависимости.  A -> B - модуль А зависит от В. API модуль содержит интерфейсы и модели данных фичи, с которыми могут работать все другие модули. Lint правило: На API модуль могут ссылаться любые другие модули. BL модуль содержит бизнес-логику фичи. Модуль реализует API фичи. Модуль содержит internal классы - закрыт для других модулей, кроме DI компонента, которые подключается в приложение. Lint правило: На BL модуль может  ссылаться только APP модуль. UI модуль содержит интерфейс фичи. Модуль содержит internal классы - закрыт для других модулей, кроме DI компонента, которые подключается в приложение и NavGraph, который подключается в граф приложения как nested graph. Lint правило: На UI модуль может ссылаться только APP модуль. А приложение строится следующим образом: Мы создаем наши фичи модули Создаем модуль приложения (app) В app модуле собираем наш паззл компонентов из DI модулей Чтобы изменить логику фичи, вам нужно реализовать дополнительный модуль, подключить к app и заменить всего лишь одну строчку в DI, и эта логика сразу распространится по всему приложению, не важно кто и где вызывает фичу. C UI модулем есть нюанс - это граф, его нужно будет добавить в root граф app модуля. Добавляем графы наших фич в root граф нашего приложения (app). Пока только статическое формирование графа, работаю над динамической, там немало проблем. Вызов фичи выглядит следующим образом: Вот как выглядит интерфейс (по сути это просто метка) А интерфейс ModuleNavInfo содержит уже более конкретную информацию, как фичу нужно вызывать. Реализация FeatureADestination спрятана в UI модуле. Также в приложении есть navigator, который достает нужные фичи по их интерфейсам и выполняет переход. Реализация навигатора достаточно простая, вам нужно лишь вытащить зарегистрированную в DI реализацию ModuleNavInfo: ModuleNavInfo и AppNavigator можно расширить, здесь я показал самый простой пример. Например, вам точно понадобится передавать параметры и возвращать результат. Сделать это тоже можно через ModuleNavInfo. Например, для возврата результата фичи, можно добавить StateFlow и подписываться на него. Все получается лаконично и в одном месте. Также можно настроить взаимодействие с помощью внутренних сервисов, которые можно спрятать от внешнего мира в BL модулях. Код примера доступен на гитхаб. Спасибо за внимание! Android Teamlead