Как архитектурно организовать большой Django-проект (apps, services, repositories)?

Деление на приложения

Django apps стоит выделять по бизнес-возможностям: например, users, orders, billing, notifications. У каждого приложения должны быть ясные границы ответственности, собственные модели, API, тесты и публичный интерфейс для взаимодействия с другими частями системы.

Тонкие views и serializers

View или ViewSet должен отвечать за HTTP-уровень: получить запрос, проверить входные данные, вызвать use case и вернуть ответ. Serializer отвечает за преобразование и валидацию данных. Сложную бизнес-логику, транзакции и координацию нескольких моделей лучше не размещать в ViewSet или serializer.

Service layer

Services, или use cases, содержат прикладные сценарии: создание заказа, проведение платежа, отмену подписки, отправку события. Они делают бизнес-логику явной, переиспользуемой и удобной для тестирования.

from django.db import transaction


@transaction.atomic
def create_order(*, user, items):
    order = Order.objects.create(user=user)
    for item in items:
        OrderItem.objects.create(order=order, product=item.product, quantity=item.quantity)
    return order

Repositories и query services

Django ORM уже является хорошим abstraction layer, поэтому repository pattern не нужен для каждой простой модели. Его имеет смысл вводить, когда сложные запросы повторяются, нужно изолировать доступ к нескольким хранилищам или упростить тестирование. Для сложного чтения часто достаточно отдельных query services или кастомных QuerySet и managers.

Практические правила

• не создавать циклические зависимости между apps;

• выносить интеграции с внешними сервисами в отдельные adapters или clients;

• явно задавать транзакционные границы в сервисах;

• держать доменную логику независимой от HTTP и представления;

• не усложнять архитектуру до появления реальной сложности.

Как ответить на собеседовании

Я делю большой Django-проект на apps по доменам, а не по типам файлов. Views и serializers делаю тонкими, сложные сценарии и транзакции выношу в services. Repository pattern использую точечно: ORM уже покрывает простой доступ к данным, а отдельные repositories или query services полезны для сложных и повторяющихся запросов.