Как стать автором
Обновить

Комментарии 5

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


А ещё есть вопросы по содержимому статьи. Вы описываете проблему следующим образом.


в новые сервисы транзитивно попадают зависимости, несовместимые с имеющейся версией Spring.

Я так понял, что новый подход выбран как раз для того, чтобы такого не было, но ведь модуль order-open-feign-client тянет за собой спринг точно так же, как и order-open-client. Или я что-то не так понимаю?


Я пару раз прочитал статью и у меня создалось впечатление, что транзитивные зависимости создавали вам проблемы потому что сервисам, использующим ваш клиент, нужно было обновлять версии спринга синхронно с order-api. А перевести сервис на новую версию Спринга это может быть небыстро.


И тогда вы решили, что поддерживать две версии клиента будет дешевле, чем в авральном порядке переводить сервис на новый Спринг. Я правильно понял? Или всё-таки новые версии клиентов каким-то образом и правда не тащат за собой транзитивные зависимости?

В хабы добавили. Спасибо за замечание.

Все верно, это разделение преследует 3 цели:

  1. Транзитивно получить совместимые зависимости в месте использования

  2. Не менять код в месте использования

  3. Поддерживать несколько версий клиентов одновременно

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

Полностью ли я ответил на Ваш вопрос?

Полностью ли я ответил на Ваш вопрос?

Да, вполне, спасибо )). Хотя ещё любопытно, что у вас в стартерах. Теоретически каждому клиенту может понадобиться своя конфигурация и свой собственный, например, ObjectMapper. Вы как-то делаете отдельные конфигурации для каждого клиента?

Если грубо, то как в коде на гитхабе, но фактически мы используем и@ConditionalOn...+ spring-configuratoin-metada.json, но опять таки не всегда.

ObjectMapper-ы у нас настроены однотипно, но в случае необходимости пойдем путём квалифайреов. Пока не приходилось конечно на такое идти, но примерно решение есть.

Очень больная проблема - Swagger/OpenApi, пока адекватного пути не нашли.... ну разве что убрать все аннотации из DTO и да, это не феншуйно, такой трейд-офф.

Другая проблема с ResponseEntity, но таких кейсов не много, потому изменения минимальны.

раз вы заговорили об IT-ипотеке, то откуда такое странное ограничение по возрасту 45 лет, или архитекторы и синьоры с опытом не способны погасить ипотеку?

Зарегистрируйтесь на Хабре, чтобы оставить комментарий