Концептуальная и техническая модель
На ранних этапах мы описываем предметную область: заявки, заказы, документы, платежи, интервалы консультаций, статусы и правила. Эта модель должна быть понятна экспертам предметной области и не зависеть от языка программирования.
Техническая модель появляется позже. Она нужна разработчикам и описывает, как выбранное решение может быть реализовано в ПО. Здесь возникают классы, интерфейсы, DTO, репозитории, сервисы, адаптеры, мапперы и зависимости между слоями.
Различие можно показать так:
| Концептуальная модель | Техническая модель |
|---|---|
| описывает предметную область | описывает реализацию |
| понятна предметным экспертам | понятна разработчикам |
| не зависит от языка и фреймворка | ближе к Java, C#, TypeScript или другому стеку |
| содержит предметные понятия | содержит классы, интерфейсы, DTO, сервисы |
| фиксирует смысл и правила | фиксирует ответственность и зависимости |
Переход между моделями — это не автоматическое преобразование. Концептуальный класс “Заказ” может в технической модели дать Order, OrderItem, OrderStatus, OrderRepository, OrderDto, OrderMapper, OrderApplicationService и, возможно, события вроде OrderPaid. Часть этих элементов отражает предметный смысл, часть нужна для хранения, передачи данных, координации сценария или интеграции.
Пример моста:
| Концептуальный элемент | Возможные технические элементы |
|---|---|
| Заказ | Order, OrderStatus, OrderApplicationService |
| Позиция заказа | OrderItem, OrderItemDto |
| Клиент | Customer, CustomerRepository |
| Оплата | Payment, PaymentGateway, PaymentResultDto |
| Правило отмены заказа | метод доменной модели или доменный сервис |
| История статусов | OrderStatusHistory, событие, таблица аудита |
Обратная ошибка — строить техническую модель сразу, минуя концептуальную. Тогда в системе появляются сервисы, контроллеры и DTO, но непонятно, какие предметные правила они реализуют. Модель начинает напоминать структуру фреймворка, а не проектное описание ИС.
Разделение моделей помогает общаться с разными аудиториями. Концептуальную модель можно обсуждать с экспертом предметной области: правильно ли устроены понятия, связи и правила. Техническую модель обсуждают разработчики: как распределить классы по слоям, где нужны интерфейсы, какие зависимости допустимы, какие операции должны поддержать сценарии.
Смешивание уровней обычно видно по диаграмме: рядом с предметными объектами появляются контроллеры, таблицы, DTO и внешние API. Такая схема может быть полезна как черновик, но для учебной модели её лучше разделить на концептуальное и техническое представления.
Проверять переход между моделями удобно по одному выбранному сценарию. Например, для “записаться на консультацию” в концептуальной модели должны быть студент, интервал и запись. В технической модели должны появиться элементы, которые позволяют выполнить сценарий: сервис приложения для координации, репозиторий для работы с записями, модель записи для правил, DTO для передачи данных и адаптер уведомлений, если уведомления уходят во внешний сервис.
Если технический элемент не участвует ни в одном сценарии и не объясняется проектным решением, его стоит поставить под вопрос. Возможно, он понадобится позже, но в текущей модели он выглядит преждевременным.