понимать «структура внедрения зависимостей - это детали» в чистой архитектуре

Question

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

Затем говорится, что база данных, инфраструктура внедрения зависимостей, веб-сервер и т. Д. Являются примерами этих деталей.

Вопрос в том, что я могу разработать политику высокого уровня без принятия таких деталей, как база данных, так какПока я создаю интерфейс для базы данных.Но что я не понимаю, так это как удалить «инфраструктуру внедрения зависимостей» из высокоуровневого кода политики, поскольку инфраструктура DI, такая как Spring, отвечает за создание и автоматическое подключение объектов.

Answer 1

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

Но Spring, например, можно использовать без аннотаций.

Прежде всего, использование DI-фреймворка не требуется в чистой архитектуре. Вы можете легко создавать адаптеры, использовать падежные интеракторы и т. Д. На самом нижнем слое «Framework and drivers» и вручную вводить их зависимости конструкторами или установщиками. Ни один другой слой не будет знать, как были введены их зависимости.

При использовании инфраструктуры DI внешнее разрешение требуется только для входных адаптеров, другие зависимости будут разрешаться и внедряться инфраструктурой DI. Это означает, что вы можете переключаться между структурами DI и даже внедрять без какой-либо инфраструктуры, не затрагивая ничего, кроме самого верхнего уровня "Framework and drivers".