В компании по аренде оборудования менеджер говорит клиенту: «Экскаватор забронирован». На складе это пока только запрос, который ещё могут отклонить. В программе обе ситуации называются одним статусом. Когда на ту же машину приходит следующая заявка, спор возникает уже не между терминами, а между двумя обещаниями клиентам.
Domain-Driven Design, или DDD, предлагает разрабатывать модель вместе с людьми, которые знают предметную область, и использовать её в программе. В нашем примере предметная область — правила аренды. Начать нужно с различия между намерением, резервом и подтверждённым обязательством, а не с выбора названий папок.
Разобрать спорный случай до обсуждения схемы данных
Пригласите менеджера, диспетчера, сотрудника склада и разработчика. Возьмите конкретную заявку: машина нужна завтра, предыдущую аренду продлили, клиент уже внёс обеспечение. Кто вправе обещать наличие? В какой момент техника исключается из доступного фонда? Что происходит, если её вернули с повреждением?
Ответы стоит проверять на документах и реальной последовательности работы. Один эксперт может описывать официальный порядок, другой — исключение, без которого подразделение давно не справляется. Команде нужно увидеть оба варианта. Нельзя молча объявить любой привычный обход правил нормой, но и строить систему так, будто его никогда не бывает, рискованно.
Если специалисты расходятся по самому правилу, архитектор не должен незаметно выбирать политику компании. Нужен ответственный за бизнес-решение. Модель делает разногласие видимым; она не заменяет полномочий решить, когда компания принимает обязательство перед клиентом.
Общий язык проверяется действиями
Договоримся, что «запрос на аренду» ещё не удерживает машину, а «подтверждённый резерв» удерживает её на согласованный период. Эти понятия должны одинаково использоваться в разговоре, интерфейсе, проверках и коде соответствующей части системы. Именно такую работу с языком описывает Ubiquitous Language.
Одного словаря недостаточно. Операция «подтвердить резерв» должна проверить условия, а не просто заменить текст статуса. Новый сотрудник должен понимать, чем подтверждение отличается от создания заявки и кто может его отменить. Непонятное значение снова станет поводом для ручных звонков, даже если классы названы аккуратно.
Для финансов «обеспечение» может означать полученную сумму и условия возврата, а для диспетчера — лишь выполнение одного условия аренды. Им необязательно разделять один огромный объект со всеми деталями. Bounded Context задаёт область, внутри которой модель имеет согласованный смысл; между областями нужны явные договорённости.
Как правило становится ограничением программы
В примере есть условие, которое нельзя нарушать: одна машина не должна получить два подтверждённых резерва на пересекающиеся периоды. Такое неизменно выполняемое правило называют инвариантом. Проверить его только в форме браузера недостаточно: заявку могут принять через интеграцию или одновременно из двух окон.
Агрегат в DDD задаёт границу согласованного изменения связанных данных. Его выбирают под правила, которые требуется защищать вместе, а не под все отношения, существующие в компании. Базовые понятия сущностей, объектов-значений и агрегатов разобраны в Azure Architecture Center.
Но название Aggregate не останавливает конкурирующие запросы. Для резерва всё равно нужен корректный механизм записи: транзакция, проверка версии, ограничение базы или другой способ, соответствующий модели. Ответственность доменной модели за сохранение правил отдельно обсуждает документация Microsoft о проверках инвариантов. Реализацию необходимо испытать при одновременной работе.
Граница может оказаться неудачной в обе стороны. Если она слишком мала, важное правило потребует ненадёжной последовательности отдельных изменений. Если включает весь парк техники, независимые бронирования начнут мешать друг другу. Выбор уточняют по ограничениям и нагрузке, а не по желанию разместить всё в одной красивой модели.
Список доступной техники при этом может обновляться с задержкой. Это приемлемо лишь при понятном поведении: окончательное подтверждение проверяет актуальное состояние, а клиент до него видит заявку, не обещание. Модель должна описывать и такой отказ, чтобы интерфейс не выдавал предварительный расчёт за закреплённый резерв.
На что тратить моделирование, а что оставить простым
Не весь продукт одинаково сложен. Распределение техники, продление аренды и замены при поломке могут определять качество услуги. Для них полезно подробно разбирать правила. Редактированию справочника стандартных контактов может хватить обычных форм и проверок.
Отдельная машина сохраняет идентичность, даже когда меняет название или состояние. Период аренды или сумма с валютой, напротив, часто описываются своими значениями. Эти различия помогают избежать ошибок, но не требуют применять каждый известный паттерн к каждому полю.
DDD не обязывает выделять микросервисы, заводить событийный журнал или разделять чтение и запись. Модели можно реализовать внутри существующего приложения. Различие стратегического анализа и тактических приёмов описывает руководство по анализу предметной области. Выбор способа развёртывания следует обсуждать отдельно.
У модели есть версия, даже если её не записали
Компания может изменить правило: теперь часть клиентов получает резерв до внесения обеспечения. Нужно определить, применяется ли это к прежним заявкам, кто подтверждает исключение и как соседние системы узнают о новом состоянии. Пересчитать все старые операции по сегодняшним правилам не всегда допустимо для продукта.
Полезно связать решение с примерами и тестами: подтверждение без обеспечения, продление занятого периода, возврат повреждённой машины, отмена после выдачи. Эксперт должен понимать ожидаемый результат без чтения программного кода. Разработчик — уметь показать, где этот результат обеспечивается.
Начать можно с одного правила, которое регулярно вызывает переделки или обращения в поддержку. Выяснить смысл, назначить владельца, изменить небольшой участок программы и проверить следующий похожий случай. После этого станет видно, помогает ли модель или лишь добавляет терминов. Для аренды критерием будет вполне приземлённая вещь: клиент, менеджер и склад одинаково понимают, какая техника действительно обещана и на какой срок.