Python Web & Scripts — Django, FastAPI, скрипты
5 Django-ошибок, которые ломают проект не в коде, а в архитектуре
Django часто ругают за «магии», но в реальности проблемы обычно в том, как проект собран. Самые дорогие ошибки повторяются из репы в репу: один большой app, смешанные домены, и модели, которые знают слишком много о внешнем мире.
— Ставить всё в один app. Потом сложно выделить платежи, пользователей, каталог и интеграции без боли.
— Тянуть бизнес-логику в views. В итоге тесты хрупкие, а повторное использование почти нулевое.
— Делать модели жирными, но без границ: `save()`, сигналы, кэш, внешние запросы — всё в одном месте.
— Игнорировать сервисный слой. Когда появляется фоноваая задача или API-метод, код начинают копировать.
Рабочее правило простое: model хранит состояние, service — правила, view — вход и выход. Если в сервисе уже есть 200 строк, это не повод «добавить ещё чуть-чуть», а сигнал резать на сценарии и выделять зависимости.
Ещё один маркер зрелости — тестируемость. Если бизнес-поток нельзя прогнать без HTTP и базы, архитектура уже перепутала уровни. Для Django это особенно заметно на проектах, где быстро растут интеграции и админка.
Чем раньше проект разделён по ответственности, тем дешевле потом добавлять фичи, очереди и API без переписывания половины кода.
3 ·