Тема многомодульности уже давно витает в среде Android-разработчков. За много лет проб и ошибок, выработались определённые подходы к разбиению приложения на модули. В целом о принципах разбиения на модули есть хорошая статья Андрея Берюхова: https://habr.com/ru/company/kaspersky/blog/520766/

В статье Андрея хорошо описано как разбивать приложение на модули, что должны делать модули и как они должны друг от друга зависеть. Собственно, такой же подход к разбиению предполагается и в текущей статье. Для лучшего понимания как начать писать модули или начать делить приложение на модули  - ознакомьтесь со статьёй Андрея. Отличие текущей статьи от статьи Андрея - подход к склейке модулей. 

В данной статье описываются преимущества использования Moxy в качестве вспомогательной библиотеки при использовании MVP для Android-приложения.

Важно: здесь не сравнивается MVP с другими архитектурными подходами типа MVVM, MVI и т.п. В статье описывается почему, если в качестве архитектуры UI-ной части приложения выбран MVP, то лучше не использовать самописную реализацию MVP, а использовать Moxy.

Библиотека Moxy позволяет избежать boilerplate кода для обработки lifecycle фрагментов и активитей, и работать с View как будто оно всегда активно.
Далее под View понимается имплементация View в виде фрагмента или активити.
Под интерактором понимается сущность бизнес-логики, т.е. класс, который лежит на более низком уровне абстракции, чем Presenter.

Общие преимущества Moxy

• Активная поддержка и разработка библиотеки.
• Поддержка фичей Kotlin вроде val presenter by moxyPresenter { component.myPresenter } и presenterScope для корутин.
• Автоматическое восстановление состояния View.
• Автоматическая увязка с жизненным циклом (а отсюда отсутствие утечек Активити и прочей подобной прелести).
• Обращения к View происходят через не-nullable viewState. Нет риска, что какая-то команда View потеряется.
• Весь lifecycle экрана сводится к двум коллбэкам презентера — onFirstViewAttach() и onDestroy().
• Время разработки экранов сокращается — не нужно писать лишний код для обработки lifecycle и сохранения состояний.