Планирую в скором времени опубликовать описание. На данный момент идет идет процесс внедрения и дальнейшей разработки. Подробнее можно спросить у меня в телеграмме: https://t.me/Tepex — постараюсь по возможности ответить.
P.S. Возможно тем, кто занимается данной темой известна статья, описывающая схему «ленивого» связывания модулей: https://habr.com/ru/post/536106/
В моем опыте построения и процесса разработки мультимодульных схем я пришел к необходимости создания автоматизированной системы управления зависимостями и сборки поверх Gradle, т.к. мультимодульность предполагает высокую градацию проекта на модули. Модули «мельчают» и, как следствие, их становится много. А в силу их высокой обособленности и независимости, они имеют свои жизненные циклы. Управлять этим хозяйством без автоматизации становится большой болью. Да и просто не реально. К тому же (и главное!) автоматизация зависимостей и сборки позволяет выстроить всю производственную цепочку разработки от бизнес-аналитики до тестирования и релиза.
Это уже вопрос к архитектуре. Такой кейс — хороший маркер: как так получается? Архитектура ведь не только про гибкость, но и про жесткость — принудительно пресекать разные вольности компоновки. Фича2, например, в принципе не должна быть доступна через слой.
Чтобы отчуждать собственность — не обязательно трудиться. Куда проще выйти на большую дорогу. Древняя китайская мудрость гласит: «Самый прямой путь к богатству — грабеж. Нет возможности грабить — воруй». ))
Планирую в скором времени опубликовать описание. На данный момент идет идет процесс внедрения и дальнейшей разработки. Подробнее можно спросить у меня в телеграмме: https://t.me/Tepex — постараюсь по возможности ответить.
P.S. Возможно тем, кто занимается данной темой известна статья, описывающая схему «ленивого» связывания модулей: https://habr.com/ru/post/536106/
В моем опыте построения и процесса разработки мультимодульных схем я пришел к необходимости создания автоматизированной системы управления зависимостями и сборки поверх Gradle, т.к. мультимодульность предполагает высокую градацию проекта на модули. Модули «мельчают» и, как следствие, их становится много. А в силу их высокой обособленности и независимости, они имеют свои жизненные циклы. Управлять этим хозяйством без автоматизации становится большой болью. Да и просто не реально. К тому же (и главное!) автоматизация зависимостей и сборки позволяет выстроить всю производственную цепочку разработки от бизнес-аналитики до тестирования и релиза.
Это уже вопрос к архитектуре. Такой кейс — хороший маркер: как так получается? Архитектура ведь не только про гибкость, но и про жесткость — принудительно пресекать разные вольности компоновки. Фича2, например, в принципе не должна быть доступна через слой.
Девчонки полюбили не меня,
Девчонки полюбили программиста.
Неужели в него тоже Джексон пел?
Вот есть полезная статья про SharedFlow/StateFlow.
Есть же проекты так называемого «стабильного календаря».
И равный угол. Можно, ведь, ездить по спирали.
Галилея спалили? Видимо вы путаете с Дж. Бруно. Но его спалили разобравшись.
А как учитывать "усушку/утруску"?
Это в каких, например?
Толсто!
Надо полагать, речь идет об Андрее Ломачинском.
P.S. Опоздал с коментом — выше уже ответили.