Слоистая архитектура для Backend приложений по чистой архитектуре на FastAPI

[@СергейНауменко-ь6н]

Мне зашло, спасибо

[@doodlecloos3436]

Контент в кайф, можна вот етого вот по чаще)

[@АлександрИгоревич-я5ж]

Репозиторий - хранилище. Юзкейс должен представлять из себя простой сценарий, управление сценариями предоставляет интерактор

[@luferov]

@@АлександрИгоревич-я5ж репозиторий - хранилище? Postgres, s3 и другое хранилища 😅 репозиторий это абстракция для управления состоянием хранилищ, которое может быть внедрено от контракта. Юз кейс сценарий - ок. Интректор - ок

[@trepemz9034]

привет, допустим мне нужно сделать какую то не обычную бизнес логику, мне ее писать в отдельном сервисе? а потом в юскейсе писать что если этот сервис вернул истину то вызываю например другой сервис, так лучше делать?

[@clandast2136]

Не делай видосы о архитектуре, если ты не шаришь. Зачем выделять интерфейс под интерактор? Нету смысла. Чем у тебя является репозиторий? Это вообще не то, что подразумевают под патерном репозиторий.

[@luferov]

@@clandast2136 паттерн репозиторий штука для управления данными, БД может быть на каких-то этапах даже InMemmory, а может быть Postgres, а может быть чем-то другим, контракты управления данными - репозитории. Скидывай сюда свой видос о правильной архитектуре с твоей точки зрения))

[@clandast2136]

@@luferov так у тебя в репозиториях есть логика отправки смски/ мейла

[@clandast2136]

Там точно не про хранения речь

[@luferov]

@@clandast2136 назови это gateway у себя

[@luferov]

@@clandast2136 но как будто ты обращаешься к сервису и чисто технически можешь забирать отправленные сообщения 🤷 то есть, это сервис, часть функционала которого - отправка, как и сохранение в БД