Возможно не так. Под сервисом я имел ввиду орясины с именами вроде UserService и кучей методов, обменивающихся DTOшками. Так как юзер - бизнесовая сущность, бизнес вечно придумает что нибудь новенькое с ними - и UserService будет расти и мутировать. Помимо CRUD методов там появляются еще какие нибудь, или у CRUD методов появляются аргументы. Иногда аргументы - это DTOшки по 100500 полей, где нет гарантии что не впорешся в нул. Самое смешное что может быть интерфейс UserService, и у него за всю жизнь проекта одна единственная имплементация - UserServiceImpl. Спрашивается - на кой тогда интерфейс.

И внутри - `@autowired`ы. А с автовайредом такое дело - он их резолвит by type, либо by name, либо как там еще... То есть если даже у тебя и есть вменяемая абстракция с несколькими имплементациями, в UserServiceе придется зашить одну - по типу ли по имени или по квалифаеру - не важно. Поэтому что проку от этой абстракции - хер с ней, запилим ее таким же сервисом.

Весь энтерпрайз который я видел когда либо на спринге выглядел именно так. Что по поводу игнита - игнит все же не энтерпрайз. CollisionSpi хорош до тех пор пока стабилен. Так как игнит - фреймворк, игнитовцы могут позволить себе искусственную стабильность. Если бы игнитовцы его меняли на каждый чих, ты бы сам не рад был. Другой вопрос еще - что стоит самим игнитовцам эту стабильность поддерживать (наверно ничего, но ответить могут только сами игнитовцы).

И как бы это - а разве spring - единственная опция конфигурирования игнита? Мне казалось я его могу взять и сразу чистой джавой начать юзать.

> ничего пересобирать не надо, можно на одном деплойменте меняя параметры в файле потестить разные имплементации.

Кстати чисто субъективно меня такие фортели вообще не прикалывают. Если речь - о спринг XML, то лабать композицию на XML совсем не то же что лабать ее на чистой джаве. Выглядеть на XML она будет так громозко, и читать ее будет так муторно, что проще блин пересобрать лишний раз ИМХО. Если это - долго, проще решить проблему "почему долго", чем заниматься подобным развлекаловом с конфигом. Но это субъективно.

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

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

> не создает глобальных проблем при разработке приложений

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

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

ну я к тому что жизнь такова, что бывает такое

Если ты о микросервисах, то да, бывают. Но это не предмет гордости а вынужденная необходимость.

ну микросервисы как раз же по сути способ декаплинга самый пиздатый, не?) ну я к тому, что естественно надо правильно декомпозировать, чтобы там не было зависимостей как в паутине, но мне понравилась метафора, что микросервисы - это типа как органы у человека, а они весьма сильно друг от друга зависят)

> ну микросервисы как раз же по сути способ декаплинга самый пиздатый, не

Не думаю, хотя тут надо на примерах.

Декаплингом я согласен называть только одну вещь. Когда есть контракт, есть клиенты этого контракта и есть имплементации этих контрактов. И когда клиенты и имплмементации можно менять и множить независимо друг от друга. В случае с микросервисами - кто контракт?

REST API?

Чей? Сервисов то несколько?

Ну тут у тебя скорее всего есть вот какая фигня, называется версионирование протокола, тогда вообще похер обновились ли другие сервисы или нет

ну специально посмотрел - это ж data coupling - просто самый минимум который вообще может быть

REST API конкретного микросервиса есть контракт. Его может юзать приличное количество клиентов и сами сервисы ты горизонтально можешь неограниченно масштабировать (+ выкатка новой версии сервиса без изменения API по сути есть несколько имплементации контракта вкупе с rolling upgrade)

В том и цимес что самый минимум

Вопрос. Можем ли мы как правило рассчитывать на стабильность REST API?

Вообще обсуждение последних двух дней напоминает спор о том, как правильно держать ручку в руке. Какая разница как, если тебе удобно писать?