Переход от концепции к реализации, примечание про данные

Концептуальная модель и техническая модель

Концептуальная модель	Техническая модель
Описывает предметную область	Описывает возможную реализацию
Понятна экспертам предметной области	Понятна разработчикам
Не зависит от языка и фреймворка	Ближе к Java, C#, TypeScript или другой технологии
Содержит бизнес-понятия	Содержит классы, интерфейсы, сервисы, DTO, репозитории
Проверяется сценариями и бизнес-правилами	Проверяется sequence diagram и архитектурными зависимостями

Один концептуальный класс может породить несколько технических классов. Например, концептуальный Order может соответствовать доменной модели, DTO для API, ORM entity, mapper, repository и сервисным методам. Обратная ситуация тоже нормальна: технический класс может не иметь прямого предметного аналога, если он нужен для инфраструктуры, интеграции или организации слоя приложения.

Переход от одной модели к другой является проектным решением. Концептуальная модель говорит: в предметной области есть заказ, у заказа есть позиции, статус, клиент и правила изменения состояния. Техническая модель должна ответить на другие вопросы: какой класс отвечает за создание заказа, где проверяются правила, через какой интерфейс заказ сохраняется, какие данные уходят наружу, какие классы участвуют в сценарии.

Например, концептуальный Order может перейти в несколько элементов технической модели:

Order как доменный объект или модель;
OrderDto как структура данных для передачи через API;
OrderRepository как интерфейс сохранения и загрузки заказов;
OrderMapper как преобразователь между моделью и DTO;
OrderApplicationService как класс, координирующий сценарий оформления заказа;
OrderStatus как перечисление допустимых состояний.

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

Типичная ошибка — смешать уровни в одной диаграмме. Если рядом с предметными классами Заказ, Клиент и Платёж появляются OrderController, PaymentDto и PostgresOrderRepository, диаграмма перестаёт быть концептуальной. И наоборот, если техническая диаграмма содержит только предметные классы без сервисов, интерфейсов и зависимостей, она не показывает, как сценарии будут реализованы программно.

Архитектура данных как мост

В этом курсе мы не превращаем диаграмму классов в ER-диаграмму и не углубляемся в проектирование баз данных, но связь с архитектурой данных нужно понимать.

Практические соответствия:

концептуальный класс не обязан становиться таблицей один к одному;
ассоциация может стать внешним ключом или таблицей связи;
класс ассоциации часто становится таблицей связи с собственными атрибутами;
техническая модель может включать ORM entity, DTO, repository и mapper;
часть constraints может перейти в ограничения целостности данных;
некоторые вычисляемые атрибуты не хранятся, а рассчитываются.

Важно не смешивать уровни. На концептуальной модели мы объясняем смысл предметных объектов. На технической модели показываем, какие классы нужны для реализации выбранных сценариев. На уровне данных уже решается, как именно это будет храниться.

Техническая модель также готовит материал для диаграммы последовательности. Участники sequence diagram должны браться не из воздуха, а из технической диаграммы классов: контроллеры, сервисы, репозитории, адаптеры, модели и внешние интерфейсы. Сообщения на sequence diagram должны соответствовать операциям этих классов или хотя бы быть совместимыми с их ответственностью.