Где лучше размещать бизнес-логику: в моделях или в сериализаторах?

Бизнес-логику лучше размещать в моделях или в отдельных сервисных слоях.

Преимущества размещения в моделях:

• Согласованность: Логика тесно связана с данными, с которыми работает.
• Переиспользование: Методы модели доступны в разных частях приложения (views, shell и т.д.).
• Транзакции: Легко использовать транзакции базы данных для обеспечения атомарности операций.

Преимущества размещения в отдельных сервисных слоях (Service Objects):

• Разделение ответственности: Отделяет бизнес-логику от представлений и моделей.
• Тестируемость: Сервисы легче тестировать независимо.
• Чистота моделей: Модели остаются сосредоточенными на взаимодействии с базой данных.

Где НЕ следует размещать бизнес-логику:

• Сериализаторы: Сериализаторы предназначены для преобразования данных между форматами (например, Python-объекты в JSON и обратно). Они не должны содержать сложную бизнес-логику.
• Представления (Views): Представления должны быть максимально тонкими и их основная задача - взаимодействие с HTTP-запросами/ответами, вызов соответствующих сервисов или методов моделей.

Пример размещения в модели:

# models.py
class Order:
    def place_order(self):
        # Валидация
        if self.status != 'draft':
            raise ValueError("Only draft orders can be placed")
        # Изменение статуса
        self.status = 'placed'
        # Создание связанных записей (например, Invoice)
        invoice = Invoice(order=self, amount=self.total_amount)
        invoice.save()
        self.save()

Пример размещения в сервисном объекте:

# services.py
def place_order(order):
    # Валидация
    if order.status != 'draft':
        raise ValueError("Only draft orders can be placed")
    # Изменение статуса
    order.status = 'placed'
    # Создание связанных записей (например, Invoice)
    invoice = Invoice(order=order, amount=order.total_amount)
    invoice.save()
    order.save()
    return order

Выбор между размещением в моделях или сервисных объектах зависит от сложности логики и архитектурных предпочтений проекта. Как правило, простая логика, тесно связанная с конкретной моделью, может оставаться в модели. Более сложная и переиспользуемая логика лучше выносится в сервисные слои.