После прочтения некоторых связанных постов здесь и дальнейшего обсуждения в команде мы приходим к следующим выводам. Я надеюсь, что это будет полезно для других здесь.
О конфигурации XML (которую мы используем до сих пор), мы решили оставить ее для зависимостей, определенных библиотеками (независимо от того, разрабатываются ли мы или третьими лицами).
Библиотеки, по определению, предоставляют определенную функциональность и могут использоваться в различных сценариях, необязательно связанных с DI. Поэтому использование аннотаций в проектах библиотеки, которые мы разрабатываем сами, создаст зависимость библиотеки DI (в нашем случае Spring) от библиотеки, что сделает библиотеку непригодной для использования в контексте без DI. Наличие дополнительных зависимостей не считается хорошей практикой среди нашей команды (в общем, ИМХО).
Когда мы собираем приложение, контекст приложения будет определять необходимые зависимости. Это упростит отслеживание зависимостей, так как приложение становится центральным блоком объединения всех компонентов, на которые имеются ссылки, и, как правило, именно в этом месте и должно быть все подключение.
XML также полезен для нас при предоставлении имитационных реализаций для многих компонентов, без перекомпиляции модулей приложения, которые будут их использовать. Это дает нам гибкость при проведении тестирования в локальной или производственной среде.
Что касается аннотаций , мы решили, что мы можем извлечь выгоду из их использования, когда внедренные компоненты не изменятся - например, только определенная реализация для компонента будет использоваться во всем приложении.
Аннотации будут очень полезны для небольших компонентов / приложений, которые не будут изменять или поддерживать разные реализации зависимости одновременно и которые вряд ли будут составлены по-разному (например, с использованием разных зависимостей для разных сборок). Простые микроуслуги вписываются в эту категорию.
Достаточно маленькие компоненты, составленные с аннотациями, можно использовать сразу в разных проектах, не имея соответствующих приложений, чтобы покрыть их в своей конфигурации XML. Это упростит подключение зависимостей приложения и уменьшит повторяющиеся настройки.
Однако мы согласились, что такие компоненты должны иметь зависимости, хорошо описанные в нашей технической документации, чтобы при сборке всего приложения можно было получить представление об этих зависимостях без прокрутки кода или даже загрузки модуля в IDE.
Отрицательный побочный эффект компонентов, настроенных для аннотаций, заключается в том, что разные компоненты могут создавать конфликтующие переходные зависимости, и опять-таки дело за конечным приложением для разрешения конфликтов. Когда эти зависимости не определены в XML, подходы к разрешению конфликтов становятся весьма ограниченными и отклоняются от лучших практик, если они вообще возможны.
Таким образом, при работе с аннотациями компонент должен быть достаточно зрелым в отношении того, какие зависимости он будет использовать.
В общем, если наши зависимости могут различаться для разных сценариев или модуль может использоваться с разными компонентами, мы решили придерживаться XML. Очевидно, что ОБЯЗАТЕЛЬНО должен быть правильный баланс между обоими подходами и ясная идея для использования.
Важное обновление, касающееся смешанного подхода. Недавно у нас был случай с тестовой средой, которую мы создали для нашей команды QA, которая требовала зависимостей от другого проекта. Фреймворк был разработан для использования подхода аннотации и классов конфигурации Spring, в то время как указанный проект имел некоторые xml-контексты, на которые нам нужно было сослаться. К сожалению, тестовые классы (где мы использовали org.testng с поддержкой Spring) могли работать только с классами конфигурации xml или java, не смешивая оба.
Эта ситуация иллюстрирует случай, когда смешивание подходов может привести к столкновению, и однозначно следует отказаться. В нашем случае мы перенесли тестовую среду для использования контекстов Spring xml, но другие варианты использования могут подразумевать обратное.