Верно в примере такси зависит от нашей потребности.
Рассмотрим второй вариант:
Мы говорим в интерфейсе, что нужно сделать перевозку.
Есть внешний агрегатор такси. Не зависящий от нас
Значит нужен слой внешнего взаимодействия, например секретарь или логист. У которого есть метод отвези мою посылку, который нужен нам, и он адаптирует его к одному или нескольким агрегаторам.
Для меня как для заказчика (юзкейса) абсолютно не важно какой размер груди у секретаря или какие мозоли у логиста. Главное что есть кому сказать отвези.
Из этого примера видно, что слой внешнего взаимодействия зависит от слоя юзкейсов и от внешнего АПИ одновременно.
Как я понял из статьи и собственного применения, читай что можно его (описание интерфейса) расположить в одном файлике/папке/неймспейсе (зависит от языка) с МВУ
А МНУ будет подключать/наследовать МВУ для получения описание интерфейса.
Тут не понятно что имеется ввиду? Каких случаях? И просьба задать вопрос без кода, так как код должен являться результатом применения модели / принципа, а не источником.
Код сверху не описывает зависимости, так что плохо применим к описанию проблемы.
Ответ на то что понимается под зависит и использует был дан выше.
Я увидел что Вам не понятна разница между использованием реализации [интерфейсов] и зависимостью, то есть неким аналогом наследования, использования кодовой базы непосредственно.
Это тема кажется не интересной к обсуждению так как относится или к смешению контекста или глубинному не пониманию абстракций.
Читай включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию, которое как раз отвечает за понятие использует в рамках модулей бизнес логики и обычного языка.
Юзкейс может использовать реализации из (читай использует) внешнего взаимодействия
Upd Модель основана на чистой архитектуре. Если она Вам не знакома, то увы объяснение терминов может свестись к некому описанию чистой архитектуры. Что не очень продуктивно.
Я использую легковое такси. Как способ доставки моего товара от подъезда до подъезда.
Я не завишу от марки и модели автомобиля который перевезёт мой товар. Не завишу ни от чего внутри автомобиля.
Я определил интерфейс - перевезти. И его использую.
Но от его реализации я не завишу.
upd Как дополнение. В момент перевозки я использую конкретный экземпляр такси. Который предоставлен мне конкретным провайдером. Которого я могу сменить без влияния на результат.
Тут есть зависит. В в данном случае зависит (имеет зависимость) близко по смыслу к включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию.
На примере юзекйса и внешнего взаимодействия (конкретных):
Внешнее взаимодействие зависит от юзкейса.
Юзкейс может использовать реализации из внешнего взаимодействия
Это вопрос зависимости с точки зрения посторонняя бизнес логики. Тут лучше посмотреть дядю Боба на предмет чистой архитектуры в оригинале или с автоматизированным переводом.
Я приведу простой ограниченный пример:
Мне нужно сделать метод приёма заказа:
1) я определяю на русском языке понятные для бизнеса параметры на вход, параметры на выход, порядок действий.
Например: на вход пользователь, список товаров с количеством, адрес и дата доставки, на выход идентификатор заказа; порядок действий: сгенерировать идентификатор, сохранить в хранилище заказ (модель заказа) и наконец выдать ид заказа наружу
2) оцифровываю их в виде юзекйса, в котором я описываю 2 интерфейса: для генерации ид и сохранения заказа в хранилище и две структуры входной и выходной параметр. Попутно я пользую модель заказа из энтити.
Так же я делаю сам юзкейс в котором будет единственный метод "сохранить заказ"
3) И наконец я делаю реализацию сохранений и генераций. А так же внешнее апи
Из примера видно что от чего зависит с бизнесс точки зрения. С точки зрения выполнения зависимость обратная. И если писать в лоб не ориентируясь за заветы дяди Боба, то пишется от обращений в репозитории и внешнего интерфейса к логике. Буква D в солид говорит, что так не надо, а надо наоборот, в начале писать общее абстрактное а потом на него накручивать реализацию. То есть писать так как выглядит описание задачи с бизнес точки зрения.
Самый высокий уровень - entity (если вы его используете)
Затем usecase он зависит от entity. Фактически тут определяется львиная доля бизнес логики.
Затем внешнее взаимодействие - самый низкий из 3х основных. Для уточнения это уровень внешнего представления и репозиториев. Он зависит от usecase и entity. Именно на этом уровне могут появляться зависимости от Фреймворков и прочей гадости, которые нужно уметь менять как перчатки.
Верно в примере такси зависит от нашей потребности.
Рассмотрим второй вариант:
Мы говорим в интерфейсе, что нужно сделать перевозку.
Есть внешний агрегатор такси. Не зависящий от нас
Значит нужен слой внешнего взаимодействия, например секретарь или логист. У которого есть метод отвези мою посылку, который нужен нам, и он адаптирует его к одному или нескольким агрегаторам.
Для меня как для заказчика (юзкейса) абсолютно не важно какой размер груди у секретаря или какие мозоли у логиста. Главное что есть кому сказать отвези.
Из этого примера видно, что слой внешнего взаимодействия зависит от слоя юзкейсов и от внешнего АПИ одновременно.
Как я понял из статьи и собственного применения, читай что можно его (описание интерфейса) расположить в одном файлике/папке/неймспейсе (зависит от языка) с МВУ
А МНУ будет подключать/наследовать МВУ для получения описание интерфейса.
Тут не понятно что имеется ввиду? Каких случаях? И просьба задать вопрос без кода, так как код должен являться результатом применения модели / принципа, а не источником.
Код сверху не описывает зависимости, так что плохо применим к описанию проблемы.
Ответ на то что понимается под зависит и использует был дан выше.
Нет не идентично.
Ибо суть понята не до конца верно.
Реализация интерфейса может быть любой (использует), а вот объект из энтити только строгого состава зависит.
Я увидел что Вам не понятна разница между использованием реализации [интерфейсов] и зависимостью, то есть неким аналогом наследования, использования кодовой базы непосредственно.
Это тема кажется не интересной к обсуждению так как относится или к смешению контекста или глубинному не пониманию абстракций.
Прошу прощения если задел.
Читай комментарии сверху они дают различие в терминологии.
Но на всякий случай использовать в рамках статьи имеется ввиду результат деятельности.
Но бывает слово используется (причем другое) для описания использования кодовой базы что является зависимостью в терминологии статьи и комментариев :)
Нет usecase зависит от entity и использует реализации из внешнего взаимодействия.
Я прям над вашим комментарием написал разницу между зависит и использует.
Нет он от него зависит
Usecase зависит от entity.
Читай включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию, которое как раз отвечает за понятие использует в рамках модулей бизнес логики и обычного языка.
Юзкейс может использовать реализации из (читай использует) внешнего взаимодействия
Upd Модель основана на чистой архитектуре. Если она Вам не знакома, то увы объяснение терминов может свестись к некому описанию чистой архитектуры. Что не очень продуктивно.
Я использую легковое такси. Как способ доставки моего товара от подъезда до подъезда.
Я не завишу от марки и модели автомобиля который перевезёт мой товар. Не завишу ни от чего внутри автомобиля.
Я определил интерфейс - перевезти. И его использую.
Но от его реализации я не завишу.
upd Как дополнение. В момент перевозки я использую конкретный экземпляр такси. Который предоставлен мне конкретным провайдером. Которого я могу сменить без влияния на результат.
Тут есть зависит. В в данном случае зависит (имеет зависимость) близко по смыслу к включает, наследует использует кодовую базу непосредственно. Не путать с использует реализацию.
На примере юзекйса и внешнего взаимодействия (конкретных):
Внешнее взаимодействие зависит от юзкейса.
Юзкейс может использовать реализации из внешнего взаимодействия
В теле сатьи есть определения МВУ и МНУ. Они чётко дают понимание терминов выше и ниже.
Кажется мы разговариваем о разном. Я предлагаю ещё раз вернуться к определениям и понять в них есть слово использует но нет слова зависит.
А вот зависимость кодовой базы - это уже применение принципов скрываемых за идеей, например за SOLID.
Что такое формально определить?
Что хочется услышать на это? Есть ли непротиворечивый пример?
Суть вопроса не понятна.
Ибо выше и ниже чётко определяется в статье.
Использует - это базовое слово.
пользоваться -зуюсь, -зуешься; несов. 1. (несов. воспользоваться) чем. Прибегать к чему-л., обращаться к чему-л. для своих нужд и потребностей.
Юзкейс использует реализацию интерфейса и в конечном счёте хранилище, если реализация его использует.
Тут появляется очень много имхо ненужной конкретики: инфраструктура, геттеры, конструктор. Они имхо к сути не имеют никакого отношения.
Не понимаю сути вопроса.
Тут хорошее определение: использует, а не зависит.
"""При этом у многих людей в разговорной лексике "верхнее" потому и "верхнее", что зависит от "нижнего"."""
Непонятно ни про многих ни про зависимость. Кажется ровно наоборот.
Это вопрос зависимости с точки зрения посторонняя бизнес логики. Тут лучше посмотреть дядю Боба на предмет чистой архитектуры в оригинале или с автоматизированным переводом.
Я приведу простой ограниченный пример:
Мне нужно сделать метод приёма заказа:
1) я определяю на русском языке понятные для бизнеса параметры на вход, параметры на выход, порядок действий.
Например: на вход пользователь, список товаров с количеством, адрес и дата доставки, на выход идентификатор заказа; порядок действий: сгенерировать идентификатор, сохранить в хранилище заказ (модель заказа) и наконец выдать ид заказа наружу
2) оцифровываю их в виде юзекйса, в котором я описываю 2 интерфейса: для генерации ид и сохранения заказа в хранилище и две структуры входной и выходной параметр. Попутно я пользую модель заказа из энтити.
Так же я делаю сам юзкейс в котором будет единственный метод "сохранить заказ"
3) И наконец я делаю реализацию сохранений и генераций. А так же внешнее апи
Из примера видно что от чего зависит с бизнесс точки зрения. С точки зрения выполнения зависимость обратная. И если писать в лоб не ориентируясь за заветы дяди Боба, то пишется от обращений в репозитории и внешнего интерфейса к логике. Буква D в солид говорит, что так не надо, а надо наоборот, в начале писать общее абстрактное а потом на него накручивать реализацию. То есть писать так как выглядит описание задачи с бизнес точки зрения.
Берём чистую архитектуру:
Самый высокий уровень - entity (если вы его используете)
Затем usecase он зависит от entity. Фактически тут определяется львиная доля бизнес логики.
Затем внешнее взаимодействие - самый низкий из 3х основных. Для уточнения это уровень внешнего представления и репозиториев. Он зависит от usecase и entity. Именно на этом уровне могут появляться зависимости от Фреймворков и прочей гадости, которые нужно уметь менять как перчатки.