Что хотят услышать интервьюеры:

В Django сигналы организованы по паттерну Observer. Он позволяет одним частям приложения реагировать на события, происходящие в других частях, без жесткой связки между ними. Это удобно для побочных действий вроде логирования, отправки уведомлений или обновления связанных данных.

Определение:

Observer — это поведенческий паттерн, в котором объект-источник события уведомляет подписчиков о произошедших изменениях. В Django сигнал играет роль события, а обработчики сигнала — роль наблюдателей. Такой подход помогает вынести побочную логику из основного кода и сделать систему более модульной.

Пример использования:

Например, после создания пользователя нужно автоматически отправить приветственное письмо. Вместо того чтобы вставлять эту логику в код регистрации, можно подписаться на сигнал post_save модели пользователя.

from django.db.models.signals import post_save
from django.dispatch import receiver
from django.contrib.auth.models import User

@receiver(post_save, sender=User)
def send_welcome_email(sender, instance, created, **kwargs):
    if created:
        print(f"Отправляем приветственное письмо пользователю {instance.username}")

Пояснение кода:

Код не требует сложного разложения, но логика такая: при сохранении объекта User Django вызывает сигнал post_save. Декоратор @receiver регистрирует функцию как обработчик этого события. Параметр created позволяет отличить создание новой записи от обновления существующей, чтобы письмо отправлялось только один раз.

Ключевые моменты:

В Django сигналы основаны на паттерне Observer.
Источник события не знает, кто именно на него подписан.
Подписчики реагируют на события через обработчики сигналов.
Сигналы удобно использовать для побочной логики: уведомлений, логирования, синхронизации данных.
Важно не злоупотреблять сигналами, чтобы не скрывать бизнес-логику и не усложнять отладку.

Какой архитектурный паттерн используется для организации сигналов в Django?