Похоже слово "виноват" плохо в контекст дискуссии ложится.

Если истории нет и никто не способен найти первопричину, то и проблему конкретно, технически и безличностно непонятно на основании чего формулировать. И никто для себя никаких выводов не сделает, потому что первопричины не увидит.

На основании кода легко сформулировать. Мы должны делать так, а делаем по-другому.

Новичку - нелегко. Если сменится пара поколений девелоперов - тоже нелегко.

И как раз в организации и мониторинге процессов и информационных потоков внутри команды и есть роль тимлида ИМХО.

Пользуясь временным оживлением в чатке, хочу задать вопрос адептам элегантных объектов (и подозреваю что не только им).
Какое там отношение к IoC в целом-то?

Понятно что оно как бы не везде надо (а где-то не надо вообще), но если речь идёт о кровавом энтерпрайзе, то возможность подложить свою jar в classpath и поменять имплементацию некоторого абстрактного сервиса через правки в конфиг-файле выглдядит норм.
Классический юзкейс: 1 продукт - N кастомизаций под разные проекты. Продуктом тут можно считать не только прикладное решение типо CRM, но и БД.
В качестве примера могу Apache Ignite привести - у них там через спринговый конфиг вся кастомизация единообразно делается, начиная от простого выставления настроек и заканчивая тем что можно свою имплементацию шедулирования джоб в гриде подсунуть, например.

Какие тут альтернативные решения предлагаются?
Только форки, только хардкор? Вооружиться рефлекшеном и идти писать свой спринг без фатального недостатка?

Я сначала подумал, что речь идёт о LOC(lines of code)

У меня положительное отношени к IoC, если его использовать только там где это действительно нужно.

К IoC - отношение норм. К имплементации IoC в виде DI контейнеров - больше негативное (https://www.yegor256.com/2014/10/03/di-containers-are-evil.html). Особенно к инжекциям через аннотации. Отношение к рефлекшену - строго негативное. Свой спринг писать нет нужды - как правило здравая композиция спринг как DI контейнер успешно заменяет. По поводу конфигурации вещей через конфиги - во первых, когда у тебя 100500 сингл-респонсибл классов без жеских зависимостей, всегда можно написать новую композицию - это даже легче чем писать новый конфиг. Кроме того, как правило конечному пользователю настолько гибкий конфиг как Spring XML не нужен

ээээ
т.е. чё, форкаем если нужна кастомизация?

Почему форкаем. Берем зависимости с классами и композируем из них решение.

Щас попробую пример придумать

Чёт пока что выглядит что вся идея сводится к тому чтобы заменить xml файл на телескопический конструктор.
Т.е. чтобы настроить Apache Ignite видимо предлагается править  .java файл и каждый раз его перекомпилировать.
Идея имеет право на существование, но кажется несколько переоценённой.

Ну вот например https://github.com/skapral/puzzlerbot. Это - мой тул для PDD (https://www.yegor256.com/2010/03/04/pdd.html). HL архитектура его сосредоточена в puzzlerbot-core: есть сущность PuzzleSource как источник паззлов, есть сущность IssueTracker куда паззлы записываются, и есть Puzzle - объект с инфой о паззле. Есть поддержка для github и gitlab - PuzzleSourceом в этом случае выступают комменты из закрытых issues и PRов, а IssueTracker - это issues из GitHub и GitLab соответственно. Теоретически если у тебя как клиента есть какая нить альтернативная идея, как замутить PDD, можно не дожидаясь меня как продукт оунера взять модули puzzlerbotа и запилить свой эндпойнт с нужной композицией внутри. Например сделать так чтобы паззлеры сканировались в PRах на гитхабе, а создавались в багтрекере на гитлабе. Если есть идея которая не покрывается текущей имплементацией (типа "нужна поддержка атлассиан") - берешь, имплементируешь зависимости из core и композируешь эндпойнт из них. Мож даже перелицензировать. Теоретически ничто не мешает тебе взять мои зависиости и запилить XML конфиг который их свяжет как тебе нужно в один эндпойнт. Я так у себя не сделал потому что не вижу в этом практической нужды просто.

Как я сказал - отношение негативное в первую очередь к инжекциям через аннотации, то есть когда конфигурация явно или неявно размазана по компонентам. К spring XML лично у меня отношение как "ну какбэ ок, но муторно, и зачем...".

спасибо за ссылку с примером - я ознакомлюсь ))

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

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

Я вижу такие проблемы:

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

- Сервис с т.з. ЕО - матерное ругательство. Егор скажет что сервис - не объект а сборник процедур (да, знаю, звучит неубедительно). Я добавлю что сервис почти всегда не сингл-респонсибл, его интерфейс не сегрегирован и из-за этого он как правило безмерно растет и жестко связывается с большим количеством зависимостей. Уследить за его ростом трудно, рефакторить потом муторно.

Сервисы более менее уместны на границах между приложениями. Ака REST-сервис. С точки зрения поддерживаемости и реюзабельности сервис ИМХО - дно.

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

возможно я как-то не так использую слово "сервис" и там Егор что-то другое под этим понимает. можно компонентой наверно назвать. в любом случае из примера думаю понятно о чём речь