Тактические паттерны DDD отвечают на вопрос «как оформить доменную модель в коде»: Entity, Value Object, Aggregate, Domain Event. Но у этого вопроса есть предшественник, который часто проскакивают: а откуда берётся сама модель? Почему агрегатом стал «Заказ», а не «Корзина»? Почему «адрес» — Value Object, а «клиент» — Entity? Ответы приходят не из паттернов, а из слоя ниже — из системы понятий домена. Её называют онтологией, и это самый недооценённый этап DDD.
Онтология: что это и почему она уже есть
Онтология домена — это описание его понятий, их свойств, связей и правил: «заказ состоит из позиций», «у заказа один клиент», «отменённый заказ нельзя оплатить». Никакого кода — только смысл.
Ключевой факт: онтология есть у любого проекта, даже если её никто не записывал. Команда всё равно оперирует понятиями — просто у каждого в голове своя версия. DDD-практики — это, по сути, способы сделать систему понятий явной и общей: перемалывание знаний (knowledge crunching) добывает понятия у экспертов, единый язык фиксирует словарь, ограниченные контексты очерчивают границы, внутри которых слова значат ровно одно.
Важно и второе: модель не бывает «истинной» — только подходящей. «Клиент» в контексте продаж и в контексте доставки — два разных понятия, и это не беспорядок, а причина, по которой bounded context вообще существует: он граница системы понятий, а не папка в репозитории.
Как понятия становятся строительными блоками
Почти любая онтология сводится к пяти элементам: объект, отношение, состояние, событие, правило. А теперь посмотри на тактический словарь DDD — это те же пять элементов, оформленные в код:
| Элемент онтологии | В доменной модели |
|---|---|
| Объект с идентичностью («этот конкретный заказ») | Entity / Aggregate Root |
| Объект-значение («адрес», «денежная сумма») | Value Object |
| Отношение («заказ состоит из позиций») | связи внутри агрегата или ссылки по id между агрегатами |
| Состояние и переходы («placed → paid», «из cancelled выхода нет») | статусная модель агрегата |
| Событие («заказ оплачен») | Domain Event |
| Правило («сумма позиций равна сумме заказа») | инвариант агрегата |
Отсюда практический порядок работы: сначала честно выписать понятия, связи, состояния и правила — простым текстом, на странице; затем эти элементы почти механически раскладываются по паттернам. Граница агрегата перестаёт быть искусством: агрегат — это кластер понятий, который должен меняться атомарно, чтобы не нарушить правило. «Заказ + позиции» — один агрегат именно потому, что инвариант «сумма позиций = сумма заказа» связывает их в одно целое.
Когда шаг с онтологией пропускают и «сразу проектируют агрегаты», паттерны вешаются на неосмысленные понятия: агрегаты нарезаются по таблицам, Value Object'ы не находятся (всё — Entity), а инварианты обнаруживаются постфактум — в проде.
Агрегат — не таблица
Отдельная ловушка на этом пути — подменить модель понятий схемой хранения. Симптомы знакомы: агрегат «нарезан» ровно по таблице; «заказ» и «позиции» — два независимых репозитория, потому что «это же две таблицы»; понятие «просроченный платёж» отсутствует в модели, потому что «это просто WHERE».
Правильное направление зависимости обратное: модель понятий первична, схема БД — способ её хранения. Один агрегат может лежать в трёх таблицах; репозиторий существует ровно для того, чтобы спрятать это от домена. Проектируй понятия → агрегаты → и только потом схему, под запросы и нагрузку. Подробный разбор этой ловушки — в статье «Концептуальная модель — не схема базы данных».
Онтология, спека и AI
У явной системы понятий сегодня есть третий потребитель, помимо команды и кода, — AI-агент. Записанная онтология (словарь, состояния, инварианты) — это то, что превращает промпт в спецификацию: агент не угадывает, можно ли оплатить отменённый заказ, — это записано. Весь конвейер выглядит так: онтология → доменная модель → спека → код (человеком или агентом) → приёмка по инвариантам. DDD и работа с AI здесь не конкурируют, а стоят на одном фундаменте — явной системе понятий. Базовый разбор онтологий без DDD-контекста — в статье «Система понятий: онтология простыми словами».
Коротко
- Доменная модель вырастает из онтологии — системы понятий домена (понятия, связи, состояния, события, правила). DDD-практики делают её явной и общей.
- Пять элементов онтологии почти механически ложатся на тактические паттерны: объект → Entity/Aggregate, значение → VO, состояние → статусная модель, событие → Domain Event, правило → инвариант.
- Граница агрегата — не искусство, а следствие правил: агрегат — кластер понятий, меняющийся атомарно ради инварианта.
- Агрегат ≠ таблица: модель понятий первична, схема БД — способ хранения, репозиторий прячет её от домена.
- Явная онтология — общий фундамент DDD и работы с AI: из неё вырастают и агрегаты, и спека для агента.
Как добыть эту систему понятий у бизнеса — в следующей статье: Event Storming.