ходит по вс или graphql?
нет, именно представь у тебя меняется какой-то сервис в юзкейсе в зависимости от того откуда пришел запрос
я юзкейсы такие передаю в адаптеры. И уже эти адаптеры сами решают, когда вызвать юзкейс это primary adapters Они могут быть любые, хттп, грпс, графкл, вс
каким слоем является эти адаптеры ?)
в архитектуре портов адаптеров - адаптеры в чистой interface adapters
смотри, тебе нужно в хттп лишить очков 10 при неудачи, в вебсокете 20 очков лишить надо (просто допустим) ты это как будешь в инфре делать)
поясни пж, что значит лишить 10 очков? блин 20 секунд слоумод - сурово
просто убавить у юзера 10 или 20 каких нибудь тугриков (из бд), в зависимости от того откуда запрос поступит
получается, что сама информация откуда пришел запрос (каким способом) является бизнес-логикой. Поэтому будут юзкейсы вроде уменьшитьОчкиВебСокеты уменьшитьОчкиХттп
Нет, информация не является "бизнес логикой".
информация: "если запрос пришел из вс, то это 10 очков" - она является. Получается, что наша система работает определенным образом в зависимости от источника сообщения. Это бизнес-логика
у нас есть бизнес правило - снимать у человека квоту очков за запрос, откуда это забота инфры, забота юзкейса их снять
вообще инфра может зависеть от бизнес логики, но не наоборот
Не так. Ты сам озвучил бизнес правило: снять 10 очков, если это вс и 20, если это графкл.
согласен. Но я не говорил ничего этому противоречащее
нуууу) в юзкейсе ты не знаешь откуда пришел запрос, но с помощью DIP ты снимаешь необходимое количество очков, все рады, ответственность не нарушена
вай причем тут дип то. Тут направление потока выполнения (адаптер вызывает юзкейс) совпадает с направлением зависимости (адаптер зависит от юзкейса)
как бы ты сделал логику, которую ты описал, можешь рассказать?
в инфре был бы метод/класс который возвращал бы количество токенов для снятия (у каждого адаптера соответственно свой), мы это передаём в юзкейс, юзкейс вызывает этот метод
ну проблема в том, что инфра начинает знать о количестве токенов. Это бизнес-логика. Это можно реализовать еще явно передавая в юзкейс число токенов. Но тогда это число ты бы в инфре задавал константой. Знание этой константы - бизнес логика
бизнес логика начинается там, где код перестает зависеть от того откуда и как он вызван
ну я согласен с этим. Но это происходит ДО той части, где известна эта константа. То что юзкейс не стал зависимым от адаптера - это да. Но бизнес логика утекла в сам адаптер. Приложение работает по-разному в зависимости от того, как к нему отправить запрос.
не правильно написал, инфра должна отдавать количество токенов в юзкейс, и максимум что она может сделать это отправить своему адаптеру какую нибудь информацию (например для хттп ничего не отправлять) а вот для вебсокета какое нибудь сообщение аля с вас спишется хх токенов. само снятие токенов должно делаться в юзкейсе, тогда и юзкейс независем и в адаптер не протекла бизнес логика
Рядом, но не совсем. Информация, откуда пришел запрос используется бизнес логикой для определения количества снятых очков. Значит эта информация должна поступать в тот код, который реализует бизнес логику.
Обсуждают сегодня