Концептуальная модель
Когда словарь и объекты-кандидаты уже появились, их нужно собрать в концептуальную модель. Такая модель показывает, какие понятия важны в предметной области, какие связи между ними существуют, какие атрибуты значимы и какие правила ограничивают допустимые состояния.
Концептуальная модель должна быть понятна не только разработчику, но и предметному эксперту. Если эксперт не может проверить, верно ли связаны заказ, клиент, платёж и доставка, значит модель слишком рано ушла в технические детали. В концептуальной модели не обязательно показывать DTO, репозитории, контроллеры, таблицы и сервисы.
Источников у концептуальной модели несколько. Словарь даёт термины и определения. Требования показывают, какие возможности нужны системе. Сценарии и процессы показывают, какие объекты создаются и используются во времени. Бизнес-правила показывают ограничения и условия. Нефункциональные требования могут подсказать важность аудита, истории изменений или хранения событий.
Пример перехода от анализа к концептуальной модели:
| Материал анализа | Возможный элемент модели |
|---|---|
| “Студент выбирает свободный интервал” | Студент, Интервал консультации, Запись |
| “Нельзя записаться на занятый интервал” | ограничение на связь Запись — Интервал |
| “Преподаватель открывает интервалы” | Преподаватель связан с Интервалом |
| “Запись можно отменить” | состояние записи или операция отмены |
| “Отправляется уведомление” | Уведомление как событие или объект обмена |
В концептуальной модели важно различать класс, атрибут и связь. “Статус” может быть атрибутом заявки, если он просто хранит текущее значение. Но если со статусами связаны правила перехода, история изменений и ответственные участники, статус или изменение статуса может потребовать отдельного представления. “Адрес доставки” может быть атрибутом заказа в простой системе или отдельным объектом, если с адресами связаны проверки, зоны доставки и повторное использование.
Проверять концептуальную модель удобно на экземплярах. Если модель говорит, что один заказ может иметь много позиций, можно создать пример заказа с двумя позициями и проверить кратности. Если правило говорит, что оплаченный заказ нельзя редактировать, нужно увидеть, где в модели есть состояние заказа или правило, объясняющее ограничение. Если объект не удаётся показать на конкретном примере, возможно, он выделен слишком абстрактно.
Концептуальная модель — это не база данных и не код. Но она задаёт основу для последующих решений: какие понятия важны, какие связи нельзя потерять и какие правила должны пережить переход к реализации.
При построении концептуальной модели полезно начинать не с атрибутов, а с связей и правил. Атрибуты легко добавить позже, а неверная связь между понятиями ломает смысл модели. Например, важно понять, может ли студент иметь несколько активных записей, может ли интервал существовать без преподавателя, может ли уведомление относиться к нескольким событиям.
Типовая ошибка — преждевременно добавлять технические поля: id, createdAt, updatedAt, deletedFlag. Иногда они действительно важны, например для аудита, но в концептуальной модели сначала нужно показать предметный смысл. Технические поля не должны заслонять понятия области.