Использование пакетов (драгоценных камней, яиц и т. Д.) Для создания разделенных архитектур

Основная проблема

Видя хорошую поддержку, которую оказывают большинство современных программных платформ для управления пакетами (думаю gem, npmи pipт. Д.), Имеет ли смысл проектировать приложение или систему, состоящую из пакетов, разработанных внутри компании, чтобы продвигать и создавать слабосвязанную архитектуру?

пример

Примером этого может быть создание пакетов для доступа к базе данных, а также для аутентификации и других компонентов системы. Они, конечно, используют и внешние пакеты. Затем ваша система импортирует и использует эти пакеты - вместо включения их кода в свою собственную кодовую базу.

Соображения

Мне кажется, что это будет способствовать разъединению кода и поддержанию возможности сопровождения, почти в виде веб-приложения по сравнению с настольным приложением (обновления применяются почти автоматически, единая база кода для единой функциональности и т. Д.).

Похоже ли это на рациональную и разумную концепцию дизайна? Используется ли это сегодня как стандартный способ структурирования приложений сегодня?

Я уже дважды участвовал в таких проектах (оба используют nuget с .NET), и я бы сказал, что в целом это хорошая идея. Но ваш пробег может отличаться.

Не думайте ни на минуту, что это панацея, что она решит все ваши проблемы, не вызывая новых. Управление релизами получит совершенно новый уровень сложности, вам придется решать проблемы с зависимостями версий, о которых вы никогда не подозревали, и у вас будут моменты, когда вы ругаетесь на решение, потому что вам нужно обновить четыре разных пакета из-за небольшая ошибка, которую нужно быстро исправить и выпустить.

С другой стороны, вы правы, что это хорошо разделяет вещи. Если вы не переусердствуете, вы, вероятно, найдете больше случаев, когда вы думаете «о, это сработало хорошо», чем «это добавило много усилий». Если у вас есть общий код для нескольких приложений, это особенно эффективно, потому что вы можете легко обновить свои приложения независимо.

И, если вы чем-то похожи на меня, вы быстро начнете писать тестовые приложения, использующие ваши пакеты, чтобы удалить целые уровни приложения из процесса поиска ошибок. И это само по себе может стоить больше, чем стоит.

В общем, это хорошая идея. Вам нужно подумать о настройке внутреннего репозитория пакетов (обычно называемого «репозиторий артефактов» в мире Java или «pypi server» в мире Python), чтобы вы оставляли там те пакеты, которые вы не хотите или не можете ' Т релиз как открытый исходный код.

Как заметил @pdr, будьте готовы иметь свой собственный ад зависимостей , где изменение какого-либо пакета требует сначала другого изменения в другом пакете, а это означает не просто изменение строки кода, а его тестирование, возможно получение принятых изменений, сборка релиза и выгрузка релиза в вышеупомянутый репозиторий пакетов. А затем измените то, что вы хотели изменить

Единственный рецепт, который я могу вам дать из своего опыта, - попытаться минимизировать это: не полагайтесь исключительно на абстрагирование общих концепций из ваших пакетов в «общий» или «каркасный» пакет . Это может показаться очень объективной вещью, но это приведет к созданию пакета монстров, который нуждается в частых, возможно противоречивых изменениях и выпусках. Намного лучше подумайте о функциональных возможностях вашей системы и создайте вспомогательный пакет для каждого из них, как вы обрисовали в общих чертах в своем вопросе.

Кроме того, главное преимущество, которое вы получите, заключается в том, что ваши приложения изолированы от (многих) зависимостей, поэтому вы можете обмениваться ими безболезненно.