То есть, то, что "выше", потребляет (consumes) то, что ниже?
Распространяется ли это отношение на абстракции; иными словами, можно ли сказать, что модуль A потребляет (consumes) некую абстракцию из модуля Б (и в этом случае модуль А потребляет модуль Б)?
В каком-то из двух случаев не используются результаты деятельности?
Пока из ваших слов выглядит так, что зависимость всегда подразумевает использование, но использование не обязательно подразумевает зависимость. И с этим я, в принципе, согласен.
Но на всякий случай использовать в рамках статьи имеется ввиду результат деятельности.
Давайте немного расширим пример.
class OrderCreationUseCase(IOrderRepository repository)
{
void CreateOrder(string customer)
{
var order = new Entity.Order(customer);
repository.Save(order);
}
}
OrderCreationUseCase не пользуется результатами деятельности new Entity.Order? Или не пользуется результами деятельности repository.Save?
С точки зрения кода (а DIP - он про код, про отношения модулей) эти отношения идентичны, разве нет?
Нет usecase зависит от entity и использует реализации из внешнего взаимодействия.
Если в вашей терминологической системе usecase не использует entity, я, честное слово, не понимаю, что вы обозначете этим словом, и как это соотносится с бытовым пониманием.
(Потому что "очевидно что" когда usecase "использует кодовую базу непосредственно" (ваши слова), он неизбежно "использует реализацию" тоже ваши слова. Вот в обратную сторону возможны варианты. А в эту - нет.)
И это как раз и демонстрирует неоднозначность определения в статье.
оцифровываю их в виде юзекйса, в котором я описываю 2 интерфейса: для генерации ид и сохранения заказа в хранилище и две структуры входной и выходной параметр. Попутно я пользую модель заказа из энтити.
Это слово означает что-то другое, не использование?
Просто если я пойду к произвольному знакомому мне разработчику и покажу ему вот такой код
namespace UseCase
{
void CreateOrder(string customer)
{
var order = new Entity.Order(customer);
}
}
я услышу в ответ, что UseCase.CreateOrderиспользуетEntity.Order и зависит от него же.
однако, меня сильно смущает, что теперь модуль, в котором находится В не может существовать без модуля, где поселился А и интерфейс, по той простой причине, что В должен реализовывать этот самый интерфейс ?!
Именно поэтому в описании принципа есть фраза "Оба модуля должны зависеть от абстракций", которую автор поста почему-то проигнорировал.
Я явным образом спрашиваю про "использует". Вот у вас есть пример с тремя слоями:
Самый высокий уровень - entity (если вы его используете) Затем usecase он зависит от entity. Фактически тут определяется львиная доля бизнес логики. Затем внешнее взаимодействие - самый низкий из 3х основных. Для уточнения это уровень внешнего представления и репозиториев.
если мы возьмем определение из поста, в котором есть слово "использует"
Модуль верхнего уровня (далее МВУ) — это модуль, который в конечном итоге использует реализацию другого модуля. Можно провести аналогию из природы: модуль верхнего уровня — это модуль, который находится выше в «пищевой цепочке», т.е. потребляет (имеет внутри себя) код другого модуля.
и применим это слово "использует" к вашему примеру, какие будут ответы на два этих вопроса:
usecase использует entity, или нет?
usecase использует внешнее взаимодействие, или нет?
В теле сатьи есть определения МВУ и МНУ. Они чётко дают понимание терминов выше и ниже.
Для меня - не дают. Потому что они опираются на слово "используют", которого я в этом контексте не понимаю, и поэтому и спрашиваю на конкретном примере:
Самый высокий уровень - entity (если вы его используете) Затем usecase он зависит от entity. Фактически тут определяется львиная доля бизнес логики. Затем внешнее взаимодействие - самый низкий из 3х основных. Для уточнения это уровень внешнего представления и репозиториев.
В этом конкретном перечислении
usecase использует entity, или нет?
usecase использует внешнее взаимодействие, или нет?
Кстати, само по себе слово "использует"-то понятно. Проблема в том, что в приведенном вами выше примере средний слой (use-case) "использует" и entity, и внешнее взаимодействие. И это само по себе нормально, проблема только в том, что в этот момент нельзя употреблять слово "использует" для отношения "выше-ниже" (или надо признать, что этот слой "выше" остальных).
Привести определение, которое будет однозначно понято всеми сторонами обсуждения.
Есть ли непротиворечивый пример?
Да. Можно говорить, что модуль А "выше" модуля Б по уровню, если модуль А зависит от модуля Б (где "А зависит от Б" - это кодовая зависимость в терминах используемых технологий, т.е. А нельзя "скомпилировать" без Б).
Ибо выше и ниже чётко определяется в статье.
Статья сама себе противоречит, как я уже писал выше, так что нет, не определяется.
Суть вопроса очень проста: как формально определить, какой модуль "выше", чем другой.
Тут появляется очень много имхо ненужной конкретики: инфраструктура,
Инфраструктура - это один из ваших слоев (третий, если быть точным, вы его назвали "внешнее взаимодействие"). Это не "ненужная конкретика".
Использует ли слой "внешнего взаимодействия" слои use-case и entity? Опираясь на ваше же определение ниже, "обращается" ли слой внешнего взаимодействия к слоям use-case и entity?
На простом примере: когда инфрастуктура читает из БД сущность, она (по крайней мере, в большей части известных мне реализаций) явно вызывает код этой сущности: конструктор, сеттеры, возможно какие-то еще методы. Значит ли это, что инфраструктура использует сущность?
И в обратную сторону: когда юз-кейс сохраняет сущность в хранилище, он вызывает методы хранилища. Значит ли это, что он использует хранилище?
...и вы при этом говорите, что у вас микросервис? Любопытно.
Выглядит так, что ваша шина данных просто была неудачной. Но я, конечно, могу ошибаться.
А зачем?
Возможность переиспользовать одного и того же потребителя с разными реализациями.
То есть, то, что "выше", потребляет (consumes) то, что ниже?
Распространяется ли это отношение на абстракции; иными словами, можно ли сказать, что модуль A потребляет (consumes) некую абстракцию из модуля Б (и в этом случае модуль А потребляет модуль Б)?
Упомянутых в коде и в последующем вопросе к нему.
Источник DIP - код (я специально нашел одну из основополагающих статей). Поэтому и обсуждать его проще и понятнее в коде.
Да нет, в нем как раз все зависимости прекрасно видны.
Видимо, я не способен его понять. У вас уже есть как минимум два разных понимания "использует", так что проблема осталась нерешенной.
В каком-то из двух случаев не используются результаты деятельности?
Пока из ваших слов выглядит так, что зависимость всегда подразумевает использование, но использование не обязательно подразумевает зависимость. И с этим я, в принципе, согласен.
Мне-то она понятна. Но я боюсь, что то, что мне понятно, отличается от того, что понятно вам.
И это, повторюсь, подчеркивает проблему определения в статье.
Давайте немного расширим пример.
OrderCreationUseCaseне пользуется результатами деятельностиnew Entity.Order? Или не пользуется результами деятельностиrepository.Save?С точки зрения кода (а DIP - он про код, про отношения модулей) эти отношения идентичны, разве нет?
Если в вашей терминологической системе usecase не использует entity, я, честное слово, не понимаю, что вы обозначете этим словом, и как это соотносится с бытовым пониманием.
(Потому что "очевидно что" когда usecase "использует кодовую базу непосредственно" (ваши слова), он неизбежно "использует реализацию" тоже ваши слова. Вот в обратную сторону возможны варианты. А в эту - нет.)
И это как раз и демонстрирует неоднозначность определения в статье.
Цитирую ваш же текст (выделение мое):
Это слово означает что-то другое, не использование?
Просто если я пойду к произвольному знакомому мне разработчику и покажу ему вот такой код
я услышу в ответ, что
UseCase.CreateOrderиспользуетEntity.Orderи зависит от него же.В вашей терминологической системе не так?
То есть usecase использует и entity, и внешнее взаимодействие?
Это много кого смущает, и именно поэтому пишут, что оба модуля должны зависеть от абстракций.
Именно поэтому в описании принципа есть фраза "Оба модуля должны зависеть от абстракций", которую автор поста почему-то проигнорировал.
Usecase использует entity, или нет?
Я явным образом спрашиваю про "использует". Вот у вас есть пример с тремя слоями:
если мы возьмем определение из поста, в котором есть слово "использует"
и применим это слово "использует" к вашему примеру, какие будут ответы на два этих вопроса:
usecase использует entity, или нет?
usecase использует внешнее взаимодействие, или нет?
Для меня - не дают. Потому что они опираются на слово "используют", которого я в этом контексте не понимаю, и поэтому и спрашиваю на конкретном примере:
В этом конкретном перечислении
usecase использует entity, или нет?
usecase использует внешнее взаимодействие, или нет?
Кстати, само по себе слово "использует"-то понятно. Проблема в том, что в приведенном вами выше примере средний слой (use-case) "использует" и entity, и внешнее взаимодействие. И это само по себе нормально, проблема только в том, что в этот момент нельзя употреблять слово "использует" для отношения "выше-ниже" (или надо признать, что этот слой "выше" остальных).
Привести определение, которое будет однозначно понято всеми сторонами обсуждения.
Да. Можно говорить, что модуль А "выше" модуля Б по уровню, если модуль А зависит от модуля Б (где "А зависит от Б" - это кодовая зависимость в терминах используемых технологий, т.е. А нельзя "скомпилировать" без Б).
Статья сама себе противоречит, как я уже писал выше, так что нет, не определяется.
Суть вопроса очень проста: как формально определить, какой модуль "выше", чем другой.
Инфраструктура - это один из ваших слоев (третий, если быть точным, вы его назвали "внешнее взаимодействие"). Это не "ненужная конкретика".
Использует ли слой "внешнего взаимодействия" слои use-case и entity? Опираясь на ваше же определение ниже, "обращается" ли слой внешнего взаимодействия к слоям use-case и entity?
Что такое "использует"?
На простом примере: когда инфрастуктура читает из БД сущность, она (по крайней мере, в большей части известных мне реализаций) явно вызывает код этой сущности: конструктор, сеттеры, возможно какие-то еще методы. Значит ли это, что инфраструктура использует сущность?
И в обратную сторону: когда юз-кейс сохраняет сущность в хранилище, он вызывает методы хранилища. Значит ли это, что он использует хранилище?