Принцип инверсии зависимостей — куда должны идти интерфейсы?

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

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

Я видел этот вопрос, но я не Не думаю, что это отвечает на мой вопрос, если, конечно, фактический ответ не имеет значения.


person DoctorMick    schedule 08.01.2015    source источник


Ответы (1)


Он называется принципом инверсии зависимостей, потому что классическое направление зависимости от модуля более высокого уровня к более низкому уровню инвертируется следующим образом:

| HigherLevelClass -> RequiredInterface | <= LowerLevelClassImplementingTheInterface |

Таким образом, перевернутая зависимость указывает от модуля более низкого уровня к требуемой абстракции для вашего модуля более высокого уровня. Поскольку клиентский модуль (уровень вашего приложения) требует определенной функциональности более низкого уровня, соответствующая абстракция (ваш интерфейс репозитория) размещается рядом с клиентским модулем.

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

Для получения подробной информации, например. см.: http://en.wikipedia.org/wiki/Dependency_inversion_principle

person Bastian    schedule 08.01.2015