Пост 5 Django-ошибок, которые ломают проект не в коде, а в архитектуре

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