Сначала назовите правило предметной области
Пусть на занятии доступны восемь мест. Запись принимается, если есть свободное место, а один участник не может занимать два места одной и той же записью. Обсудите формулировки с человеком, который организует занятия: что означает подтверждённая запись, когда место освобождается и допускается ли лист ожидания? DDD начинается с таких смыслов и правил, а не с обязательного набора классов. В Python правило можно выразить небольшой функцией или объектом, не связывая его напрямую с HTTP-запросом и отправкой письма. Границы модели должны соответствовать задаче, а не модному названию архитектуры.
Проверьте поведение короткими примерами
При TDD сначала формулируют небольшой ожидаемый результат в тесте, получают обоснованное падение, добавляют достаточную реализацию и затем улучшают структуру, сохраняя прохождение проверок. Для мастерской полезны случаи: последнее место успешно занято, следующая запись отклонена, повтор того же запроса не создаёт вторую запись. Тест должен проверять смысловое поведение, а не повторять внутреннее устройство функции. Если проверка ломается при безопасном переименовании внутреннего помощника, возможно, она слишком тесно связана с реализацией. Быстрые тесты модели не заменяют отдельную проверку базы данных и внешних границ.
Отличайте просьбу от свершившегося факта
Команда записать участника выражает намерение и может быть отклонена. Событие запись подтверждена сообщает о произошедшем изменении. После него могут понадобиться письмо, обновление статистики или другие реакции. Не стоит объявлять подтверждение до того, как состояние надёжно сохранено. Если процесс распределён между компонентами, возникает дополнительный вопрос: как согласовать сохранение записи и передачу события? Это отдельная задача надёжности, а не автоматическое свойство использования сообщений. Для маленькой системы иногда достаточно явных вызовов внутри одного приложения. Событийная схема оправдана, когда её преимущества превышают стоимость сопровождения.
Продумайте повторную доставку и сбои
Сообщение может прийти повторно после сетевой ошибки или восстановления обработчика. Поэтому получатель должен учитывать возможность повторного выполнения. Например, одно событие не должно создавать две одинаковые записи в статистике или два независимых подтверждения бронирования. Для этого проектируют идентификаторы, правила обработки и согласованное сохранение результата. Отдельно проверьте ситуацию, когда письмо не отправилось, хотя запись уже подтверждена. Не следует незаметно отменять бизнес-факт только из-за сбоя вспомогательной реакции, если это не предусмотрено правилами. Наблюдаемость и понятный путь восстановления важны не меньше красивого разделения модулей.
Попробуйте на практике
Спроектируйте запись на занятие на бумаге, не создавая проект и не устанавливая библиотеки.
- Запишите три бизнес-правила для занятия с ограниченным числом мест и уточните значения основных терминов.
- Для каждого правила составьте пример начального состояния, действия и ожидаемого результата.
- Назовите одну команду и одно событие, сохранив различие между намерением и фактом.
- Рассмотрите повторную доставку события и отказ отправки письма. Укажите, какие данные должны остаться неизменными.
Как проверить результат. Правила проверяются независимо от почты и веб-интерфейса, событие не выдаётся до подтверждения изменения, а повторная обработка имеет определённый результат.
Частые вопросы
DDD обязательно требует микросервисов?
Нет. Границы смыслов и правил можно поддерживать внутри одного приложения. Отдельные сервисы добавляют эксплуатационную сложность и требуют самостоятельного обоснования.
Нужен ли брокер сообщений, чтобы использовать события?
Не обязательно. События могут обрабатываться внутри процесса. Внешняя доставка решает другие задачи и приносит вопросы повторов, порядка, хранения и восстановления.
Самостоятельный разбор темы. Содержание конкретной обучающей программы здесь не представлено.