Самая частая ошибка при старте фичи или сервиса: услышав задачу, инженер сразу открывает редактор и рисует таблицы. Кажется, что это и есть моделирование. На деле пропущен целый этап — и его пропуск оплачивается позже переделками схемы, кривыми API и спорами «а что мы вообще имели в виду». Разберём, что такое концептуальная модель и почему она — не то же самое, что структура БД.

Два разных вопроса

Концептуальная модель отвечает на вопрос: какие понятия есть в задаче и как они связаны? Заказ, позиция, клиент, платёж; заказ состоит из позиций; платёж относится ровно к одному заказу; отменённый заказ оплатить нельзя. Здесь нет ни слова про таблицы, индексы или JSON.

Схема БД отвечает на другой вопрос: как эти понятия хранить? В каких таблицах, с какими ключами, что денормализовать ради скорости, что положить в JSONB, что вынести в отдельный сервис.

Это два разных решения, и смешивать их — значит принимать оба одновременно и оба вслепую. Одна и та же концептуальная модель ложится на десятки разных схем: реляционную нормализованную, денормализованную под чтение, документную, событийную. Выбор схемы — инженерный компромисс под нагрузку и запросы; выбор понятий — договорённость о смысле. Когда прыгаешь сразу в таблицы, договорённость о смысле принимается молча и случайно — как побочный эффект структуры хранения.

Объект — не таблица

Отучающее упражнение: перестань считать, что понятию соответствует таблица.

  • Одно понятие — несколько таблиц. «Заказ» может жить в orders, order_lines, order_status_history — три таблицы, одно понятие.
  • Одна таблица — несколько понятий. В таблице users часто смешаны «учётная запись» (логин, пароль, роли) и «человек» (имя, контакты) — два понятия с разным жизненным циклом, склеенные структурой хранения. Именно отсюда растут боли вида «удалили пользователя — потеряли автора заказов».
  • Понятие без таблицы. «Просроченный платёж» — полноценное понятие с правилами, но в БД это просто условие WHERE, а не таблица.

Если модель понятий не записана отдельно, схема БД становится моделью понятий — со всеми её компромиссами. Через год уже никто не помнит, что склейка «учётки» и «человека» была случайностью, — и новые фичи строятся поверх неё как поверх осмысленного решения.

Что ломается без концептуальной модели

  • API повторяет таблицы. Наружу торчат user_id и джойны вместо понятий домена — клиенты API вынуждены знать твою схему хранения.
  • Переделки схемы больнее. Схему меняют под нагрузку регулярно; если она же — единственная модель смысла, каждая миграция превращается в пересмотр понятий.
  • Команда спорит «о таблицах», а на деле — о понятиях. Спор «нужна ли отдельная таблица для X» часто маскирует нерешённый вопрос «а X — это вообще отдельное понятие или атрибут Y?».
  • Агент строит по схеме. Дай AI-агенту только DDL — и он честно примет структуру хранения за модель домена, со всеми склейками и случайностями (он не переспросит).

Как моделировать до таблиц

Не нужен тяжёлый инструмент — нужен час честной работы:

  1. Выпиши понятия существительными из языка бизнеса: заказ, позиция, клиент, платёж, возврат.
  2. Свяжи их: «состоит из», «принадлежит», «относится к» — со стрелками и кратностями (у заказа один клиент; у клиента много заказов).
  3. Запиши правила и состояния: какие статусы бывают у заказа, какие переходы разрешены, что запрещено («оплатить отменённый нельзя»).
  4. Проверь на бизнесе: покажи модель тому, кто владеет задачей, — на этом уровне (в отличие от DDL) он способен найти ошибку.

Результат — страница текста или простая диаграмма. Именно она потом станет общим словарём и основой спеки для агента, а уже из неё — схема БД, спроектированная осознанно, под запросы и нагрузку.

Коротко

  • Концептуальная модель = какие понятия и как связаны; схема БД = как их хранить. Это два разных решения — не принимай их одним прыжком.
  • Одна модель ложится на десятки схем; объект ≠ таблица: понятие может жить в трёх таблицах, а таблица — склеивать два понятия.
  • Без записанной модели схема БД молча становится моделью смысла — и её случайные компромиссы застывают как «так задумано».
  • Час работы: понятия → связи с кратностями → состояния и правила → проверка на бизнесе. Потом таблицы.
  • Для AI-агента это критично вдвойне: дашь ему только DDL — получишь код, построенный на компромиссах хранения.

Дальше — единый язык: как превратить модель понятий в словарь, которым одинаково пользуются бизнес, команда и агент.