1) Вроде написано, что основано на ЧА, но сервисы почему-то знают что-то об arq и sqlalchemy, а не работают через абстракции.
2) Репозитории возвращают в сервис sqlalchemy модели, а не entity на основе датаклассов. В некоторых случаях это ок, но тут сомнительно.
3) Опять же, сервисы возвращают в хендлер модель sqlalchemy, а не dto.
4) В хендлерах создается сессия к бд. Это можно было вынести в репозиторий.
5) Зачем в хендлерах на каждую команду заново создавать сервисы и репозитории? Почему бы не сделать хендлер на основе класса, добавить тод register, который будет вешать команды на нужный метод класса, а сервисы и репозитории передать в инит?
6) Ну и в целом я бы добавил абстракций, для удобства. Чтобы в сервисах и тд в типах указывать не реализацию, которая зависит от чего-то конкретного, а абстрактные классы, реализация которых может быть любая.
1) Потому что в мире есть что-то кроме HTTP, тот же gRPC, CLI и тд. Это нарушение архитектуры. Сервисный слой не должен быть привязан к транспорту.
2) Писать нужно правильно, а не как хочется, если вы хотите писать хороший, расширяемый код. Pydantic создан для валидации, а не для БЛ. Доменные модели не должны зависеть от сторонних библиотек и сам факт использования для нмх Pydantic вызывает много проблем.
3) Выбор библиотек это часть архитектурных решений. Почему нельзя показать сразу правильный подход? RQ в async проекте это как "заряжать теслу от бензинового генератора".
Еще очень сыро.
1) Вроде написано, что основано на ЧА, но сервисы почему-то знают что-то об arq и sqlalchemy, а не работают через абстракции.
2) Репозитории возвращают в сервис sqlalchemy модели, а не entity на основе датаклассов. В некоторых случаях это ок, но тут сомнительно.
3) Опять же, сервисы возвращают в хендлер модель sqlalchemy, а не dto.
4) В хендлерах создается сессия к бд. Это можно было вынести в репозиторий.
5) Зачем в хендлерах на каждую команду заново создавать сервисы и репозитории? Почему бы не сделать хендлер на основе класса, добавить тод register, который будет вешать команды на нужный метод класса, а сервисы и репозитории передать в инит?
6) Ну и в целом я бы добавил абстракций, для удобства. Чтобы в сервисах и тд в типах указывать не реализацию, которая зависит от чего-то конкретного, а абстрактные классы, реализация которых может быть любая.
1) Потому что в мире есть что-то кроме HTTP, тот же gRPC, CLI и тд. Это нарушение архитектуры. Сервисный слой не должен быть привязан к транспорту.
2) Писать нужно правильно, а не как хочется, если вы хотите писать хороший, расширяемый код. Pydantic создан для валидации, а не для БЛ. Доменные модели не должны зависеть от сторонних библиотек и сам факт использования для нмх Pydantic вызывает много проблем.
3) Выбор библиотек это часть архитектурных решений. Почему нельзя показать сразу правильный подход? RQ в async проекте это как "заряжать теслу от бензинового генератора".
1) Почему сервисный слой знает статус коды HTTP слоя?
2) Использование Pydantic моделей в домене как по мне плохая идея. Лучше датаклассы с мапером.
3) Почему синхронный rq, а не как минимум arq?