из проектов с фласка на fastapi, попутно прикрутив ко всему этому делу докер. Насколько по вашему мнению в целом хороша архитектура, описанная на скрине? принимаются любые советы вплоть до нейминга
Это не архитектура
Непонятно что такое реально service и utils. А ещё хз что такое creator и inserter. А ещё не вижу где интерфейсы декларируются
структура* перепутал понятия
Структура должна диктоваться архитектурой
service под бизнес логику, которая будет дергаться в роутерах utils под все, что может потребоваться в service (сборка json например)
Бизнес логике не нужна сборка json. "Всё" очень плохое объяснение. Полагаю utils надо распилить на части
т.е по итогу: 1. utils преобразовать из модуля в пакет, где уже будут более явно определяться утилиты 2. в source определить пакет с интерфейсами ? creator машинально добавил, поскольку до этого пользовался сырым sql через адаптеры postgres'а и миграциями занимался как раз creator, а тут хочу потрогать алхимию с алембиком
вообще меня самого немного смущает разделение пакета source/database на операции, поскольку в один момент каждый из модулей может превратиться в кашу из 1000+ строк (хотя из-за орм может это и не так скоро произойдет). А условно паттерн "репозиторий", насколько я понял многие не жалуют. Задачи для бд опять же зачастую представляют собой сбор данных по кусочкам с разных таблиц, поэтому я не вижу выхода кроме как разделить модули в пакете database по CRUD операциям. На этот счет есть какие то практики устоявшиеся?
https://breadcrumbscollector.tech/stop-naming-your-python-modules-utils/
common :D
Ну и назови "migration". Иначе непонятно что создаём
Почему не жалуют? Норм же.
Слышал жалобы на то, что это псевдопаттерн, использование которого обусловлено лишь ленью По факту в силу того, что сам не использовал, да и в целом опыта не много - не могу судить о том насколько «репозиторий» хорошая практика
Хорошая, если он сделан в терминах бизнес логики
Обсуждают сегодня