Разве вы не сталкивались с тем, что приходится делать много обезянней работы при реализации абстракций? Особенно на этапе проектирования, когда они часто меняются, и у вас нет возможности сразу посмотреть их в деле?
Иду тем же путем, только у меня все эти настройки и инжекции выполняются в Gradle-init плагине, который применяется для проектов в рамках некоторой производственной (корпоративной) среды. Этот плагин является артефактом и забирается из Maven-репозитория добавлением init-скрипта в gradle/wrapper или на локальной машине в ~/.gradle/init.d. Сам плагин — универсальный, в нем нет хардкодинга корпоративных конфигураций. Производственная конфигурация скачивается (кешируются локально) из некоторого места внутри производственной среды (LDAP, Git-репозиторий, HTTP), которое является SSoT. Адрес и способ получения прописываются в Gradle init-скрипте. Плюс плагин занимается необходимой кодогенерацией, т.к. проекты имеют единую структуру по чистой архитектуре. И большая часть — это библиотеки, фичи, с разделением на артефакты api/impl и соответствующим подключением зависимостей compileOnly/runtimeOnly.
Производственная конфигурация в простом варианте — json-файл (или любой другой формат), где описывается производственное окружение: адреса репозиториев, мета-информация, список проектов, version catalog, общая конфигурация Android, Kotlin и т.п. вещи, общие для проектов внутри среды.
Цель — разделить кодовую базу и конфигурации. Вынести конфигурации под отдельное управление специальной роли (тим-лид, devOps, инженер по сборке). Избавить линейного разработчика от необходимости самому все это настраивать из проекта в проект, занимаясь copy-paste. К тому же это небезопастно давать возможность разработчику управлять конфигурацией. Мультимодульный подход в разработке влечет появление большого количества микро-проектов (фичей, артефактов) и управлять этим хозяйством, особенно зависимостями между ними, без автоматизации становится адом.
Планирую в скором времени опубликовать описание. На данный момент идет идет процесс внедрения и дальнейшей разработки. Подробнее можно спросить у меня в телеграмме: https://t.me/Tepex — постараюсь по возможности ответить.
P.S. Возможно тем, кто занимается данной темой известна статья, описывающая схему «ленивого» связывания модулей: https://habr.com/ru/post/536106/
В моем опыте построения и процесса разработки мультимодульных схем я пришел к необходимости создания автоматизированной системы управления зависимостями и сборки поверх Gradle, т.к. мультимодульность предполагает высокую градацию проекта на модули. Модули «мельчают» и, как следствие, их становится много. А в силу их высокой обособленности и независимости, они имеют свои жизненные циклы. Управлять этим хозяйством без автоматизации становится большой болью. Да и просто не реально. К тому же (и главное!) автоматизация зависимостей и сборки позволяет выстроить всю производственную цепочку разработки от бизнес-аналитики до тестирования и релиза.
Это уже вопрос к архитектуре. Такой кейс — хороший маркер: как так получается? Архитектура ведь не только про гибкость, но и про жесткость — принудительно пресекать разные вольности компоновки. Фича2, например, в принципе не должна быть доступна через слой.
Опоздал на конкурс, но может быть вам покажется интересным мой проект?
https://habr.com/ru/articles/935704/
Разве вы не сталкивались с тем, что приходится делать много обезянней работы при реализации абстракций? Особенно на этапе проектирования, когда они часто меняются, и у вас нет возможности сразу посмотреть их в деле?
Да, так и задумано. Копия.
var -- это ошибка на этапе написания.
К сожалению сильно опоздал на конкурс. Вот мой open source проект https://github.com/tepex/kddd-ksp-dev/tree/new-arch
Иду тем же путем, только у меня все эти настройки и инжекции выполняются в Gradle-init плагине, который применяется для проектов в рамках некоторой производственной (корпоративной) среды. Этот плагин является артефактом и забирается из Maven-репозитория добавлением init-скрипта в
gradle/wrapperили на локальной машине в~/.gradle/init.d. Сам плагин — универсальный, в нем нет хардкодинга корпоративных конфигураций. Производственная конфигурация скачивается (кешируются локально) из некоторого места внутри производственной среды (LDAP, Git-репозиторий, HTTP), которое является SSoT. Адрес и способ получения прописываются в Gradle init-скрипте. Плюс плагин занимается необходимой кодогенерацией, т.к. проекты имеют единую структуру по чистой архитектуре. И большая часть — это библиотеки, фичи, с разделением на артефакты api/impl и соответствующим подключением зависимостей compileOnly/runtimeOnly.Производственная конфигурация в простом варианте — json-файл (или любой другой формат), где описывается производственное окружение: адреса репозиториев, мета-информация, список проектов, version catalog, общая конфигурация Android, Kotlin и т.п. вещи, общие для проектов внутри среды.
Цель — разделить кодовую базу и конфигурации. Вынести конфигурации под отдельное управление специальной роли (тим-лид, devOps, инженер по сборке). Избавить линейного разработчика от необходимости самому все это настраивать из проекта в проект, занимаясь copy-paste. К тому же это небезопастно давать возможность разработчику управлять конфигурацией. Мультимодульный подход в разработке влечет появление большого количества микро-проектов (фичей, артефактов) и управлять этим хозяйством, особенно зависимостями между ними, без автоматизации становится адом.
Планирую в скором времени опубликовать описание. На данный момент идет идет процесс внедрения и дальнейшей разработки. Подробнее можно спросить у меня в телеграмме: https://t.me/Tepex — постараюсь по возможности ответить.
P.S. Возможно тем, кто занимается данной темой известна статья, описывающая схему «ленивого» связывания модулей: https://habr.com/ru/post/536106/
В моем опыте построения и процесса разработки мультимодульных схем я пришел к необходимости создания автоматизированной системы управления зависимостями и сборки поверх Gradle, т.к. мультимодульность предполагает высокую градацию проекта на модули. Модули «мельчают» и, как следствие, их становится много. А в силу их высокой обособленности и независимости, они имеют свои жизненные циклы. Управлять этим хозяйством без автоматизации становится большой болью. Да и просто не реально. К тому же (и главное!) автоматизация зависимостей и сборки позволяет выстроить всю производственную цепочку разработки от бизнес-аналитики до тестирования и релиза.
Это уже вопрос к архитектуре. Такой кейс — хороший маркер: как так получается? Архитектура ведь не только про гибкость, но и про жесткость — принудительно пресекать разные вольности компоновки. Фича2, например, в принципе не должна быть доступна через слой.
Девчонки полюбили не меня,
Девчонки полюбили программиста.
Неужели в него тоже Джексон пел?
Вот есть полезная статья про SharedFlow/StateFlow.
Есть же проекты так называемого «стабильного календаря».
И равный угол. Можно, ведь, ездить по спирали.
Галилея спалили? Видимо вы путаете с Дж. Бруно. Но его спалили разобравшись.
А как учитывать "усушку/утруску"?
Это в каких, например?
Толсто!
Надо полагать, речь идет об Андрее Ломачинском.
P.S. Опоздал с коментом — выше уже ответили.