DDD-спецификация: гайд для дизайнера интерфейсов
UI по DDD-спецификации: экраны, статусы, ошибки, валидация.
DDD дизайн UI: введение
DDD дизайн UI — дизайнер интерфейсов в DDD-проекте -- связующее звено между бизнес-требованиями и тем, что увидит пользователь. Задача дизайнера -- превратить доменную модель, бизнес-правила и сценарии из Шаблона спецификации в экраны, wireframes и компоненты дизайн-системы. Дизайнер работает совместно с бизнес-аналитиком над структурой экранов и с разработчиками над реализацией.
Ключевой принцип: интерфейс должен говорить на том же языке, что и спецификация. Если в домене объект называется "Заказ" -- на экране написано "Заказ", а не "Покупка". Если статус называется CONFIRMED -- бейдж показывает "Подтвержден", а не "Принят".
Все примеры ниже используют домен "Интернет-магазин: оформление заказа".
1. Глоссарий как источник текстов интерфейса
Раздел 2 спецификации (Ubiquitous Language) -- главный справочник для всех текстов в UI. Каждый термин из глоссария должен использоваться в интерфейсе ровно так, как он зафиксирован.
Правило: все подписи полей, заголовки колонок, тексты кнопок и сообщения берутся из глоссария. Дизайнер не придумывает альтернативные формулировки.
Примеры правильных и неправильных текстов:
| Правильно (из глоссария) | Неправильно (антислова) |
|---|---|
| Заказ | Покупка, Оформление |
| Позиция заказа | Строка, Элемент, Товар в заказе |
| Снимок товара | Товарная информация |
| Адрес доставки | Адрес получения |
| Возврат | Отмена оплаты, Рефанд |
Антислова из спецификации -- то, что не должно появляться ни на одном экране, ни в одном тултипе, ни в одном сообщении об ошибке. При проверке макетов стоит пройтись по таблице антислов и убедиться, что ни одно из них не просочилось в UI.
2. Жизненный цикл заказа для UI
Каждый статус из раздела 4 спецификации -- это отдельное состояние экрана. Для дизайнера это означает: один заказ может выглядеть шестью разными способами в зависимости от статуса.
| Статус | Бейдж | Цвет | Что показать | Активные кнопки | Заблокированные кнопки |
|---|---|---|---|---|---|
| CREATED | Создан | серый | Список позиций, адрес, кнопки редактирования | Подтвердить, Отменить, Добавить товар, Удалить товар | Отправить, Доставить |
| CONFIRMED | Подтвержден | синий | Список позиций (только чтение), ожидание оплаты | Отменить | Добавить товар, Удалить товар, Подтвердить |
| PAID | Оплачен | зеленый | Список позиций, информация об оплате | Отправить (менеджер), Возврат (админ) | Отменить, Добавить товар |
| SHIPPED | Отправлен | оранжевый | Трек-номер, информация о доставке | Доставить (менеджер) | Отменить, Отправить |
| DELIVERED | Доставлен | зеленый (темный) | Вся информация, дата доставки | -- (конечное состояние) | Все кнопки действий |
| CANCELLED | Отменен | красный | Причина отмены, дата | -- (конечное состояние) | Все кнопки действий |
Для конечных состояний (DELIVERED, CANCELLED) все кнопки действий скрыты или заблокированы. Экран становится чисто информационным.
3. Роли и экраны
Разные роли видят разный набор элементов на одном и том же экране. Матрица "роль x экран" из раздела 5 спецификации определяет, что рисовать для каждой роли.
Матрица доступа к экранам:
| Экран | Покупатель | Менеджер | Администратор |
|---|---|---|---|
| UI-001 Оформление заказа | Видит, создает заказ | -- | Видит, создает заказ |
| UI-002 Подтверждение заказа | Видит, подтверждает/отменяет | -- | Видит, подтверждает/отменяет |
| UI-003 Список заказов | Только свои заказы | Заказы своего региона | Все заказы |
| UI-004 Карточка заказа | Кнопка "Отменить" (до оплаты) | Просмотр | Кнопки "Отменить" и "Возврат" |
| UI-005 Панель менеджера | -- | Кнопки "Отправить", "Доставить" | Все кнопки |
На одном экране карточки заказа (UI-004) Покупатель видит кнопку "Отменить" только для статусов CREATED и CONFIRMED. Менеджер видит информацию без кнопок действий. Администратор видит кнопки "Отменить" и "Возврат". Дизайнер готовит варианты экрана для каждой роли.
4. Реестр экранов
Реестр из раздела 11 спецификации -- основа для дизайн-задач. Для каждого экрана зафиксировано, какие данные отображаются (из запросов раздела 9), какие действия доступны (из команд раздела 7) и какие ошибки могут возникнуть (из каталога раздела 13).
UI-001 -- Оформление заказа. Данные: список товаров с ценами (запрос GetCartItems), варианты доставки (GetDeliveryOptions). Кнопки: "Оформить заказ" (команда CreateOrder), "Добавить товар" (AddItem). Ошибки: ORDER_EMPTY, ORDER_ITEM_OUT_OF_STOCK.
UI-002 -- Подтверждение заказа. Данные: детали созданного заказа (GetOrder). Кнопки: "Подтвердить" (ConfirmOrder), "Отменить" (CancelOrder). Ошибки: ORDER_CANCEL_FORBIDDEN.
UI-003 -- Список заказов. Данные: таблица заказов (SearchOrders) -- номер, статус, количество позиций, сумма, дата. Фильтры по статусу и дате. Сортировка по дате (по умолчанию) или сумме. Пагинация по 20 записей.
UI-004 -- Карточка заказа. Данные: полная информация о заказе (GetOrder). Кнопки зависят от роли: "Отменить" (CancelOrder), "Возврат" (InitiateRefund). Ошибки: ORDER_CANCEL_FORBIDDEN, ORDER_MODIFICATION_FORBIDDEN.
UI-005 -- Панель менеджера. Данные: список оплаченных заказов (SearchOrders, status=PAID). Кнопки: "Отправить" (ShipOrder, требует ввод трек-номера), "Доставить" (DeliverOrder). Платформа: только веб.
5. Wireframe как отправная точка
ASCII-wireframe из раздела 11 спецификации -- это скелет для Figma. Он фиксирует структуру и содержание, но не визуальный дизайн.
Что нужно детализировать при переводе wireframe в макет:
- Поля формы: типы инпутов (текстовое поле для города, маска для телефона, числовой ввод для индекса из 6 цифр), placeholder-тексты, подписи
- Валидация на фронтенде: красная обводка поля, текст ошибки под полем, когда показывать (при потере фокуса или при отправке)
- Состояния кнопок: активная, заблокированная (disabled), в процессе загрузки (spinner внутри кнопки)
- Loading states: скелетоны при загрузке данных заказа, спиннер при отправке формы
- Empty states: пустой список заказов ("У вас пока нет заказов"), пустая корзина при оформлении
Wireframe показывает таблицу позиций с колонками "#", "Товар", "Кол", "Цена" и кнопкой удаления. В макете это становится полноценным компонентом с hover-эффектами, адаптивным поведением и анимацией удаления.
6. Каталог ошибок для UI
Раздел 13 спецификации содержит все ошибки системы. Задача дизайнера -- определить, где и как каждая ошибка отображается на экране.
| Код ошибки | Экран | Место показа | Текст для пользователя | Действие |
|---|---|---|---|---|
| ORDER_EMPTY | UI-001 | Inline под кнопкой "Оформить" | Заказ должен содержать хотя бы один товар | Добавить товары |
| ORDER_ITEM_INVALID_QUANTITY | UI-001 | Inline у поля количества | Количество от 1 до 99 | Исправить количество |
| ORDER_TOTAL_TOO_LOW | UI-001 | Inline под кнопкой "Оформить" | Сумма заказа должна быть не менее 1 руб. | Добавить товары |
| ORDER_CANCEL_FORBIDDEN | UI-002, UI-004 | Modal | Нельзя отменить оплаченный заказ. Обратитесь к администратору | Закрыть модал |
| ORDER_MODIFICATION_FORBIDDEN | UI-004 | Toast | Изменение заказа невозможно в текущем статусе | Автоматически скрыть через 5 сек |
| ORDER_ITEM_OUT_OF_STOCK | UI-001 | Banner над таблицей позиций | Товар закончился на складе | Убрать товар или уменьшить количество |
| ORDER_NOT_FOUND | UI-004 | Полный экран (full page) | Заказ не найден | Ссылка на список заказов |
| CATALOG_SERVICE_UNAVAILABLE | UI-001 | Banner вверху страницы | Не удалось загрузить данные о товарах | Кнопка "Повторить" |
| PAYMENT_SERVICE_UNAVAILABLE | UI-002 | Modal | Сервис оплаты временно недоступен | Кнопка "Повторить через минуту" |
Типы отображения ошибок: inline -- валидация полей, рядом с элементом; toast -- информационное, не блокирует работу; modal -- критичное, требует подтверждения от пользователя; banner -- предупреждение, видно на всей странице; full page -- заменяет содержимое экрана.
7. Бизнес-правила и валидация на фронтенде
Не все бизнес-правила (раздел 6) можно проверить на клиенте. Дизайнер должен знать, какие проверки дают мгновенную обратную связь, а какие требуют запроса к серверу.
Проверять на клиенте (мгновенная обратная связь):
- BR-1 (непустой заказ): кнопка "Оформить" заблокирована, если список позиций пуст
- BR-2 (количество 1--99): числовой инпут с min=1, max=99, валидация при вводе
- BR-3 (сумма >= 1 руб.): итог пересчитывается на лету, предупреждение при сумме ниже минимальной
Проверять только на сервере (ответ после отправки):
- BR-4 (статус для отмены): клиент может не знать актуальный статус (конкурентные изменения)
- BR-5 (дубликат товара): логика объединения позиций выполняется на сервере
- BR-6 (изменение только в CREATED): статус мог измениться между открытием экрана и нажатием кнопки
Для серверных ошибок дизайнер предусматривает состояние "ошибка после отправки": кнопка возвращается в активное состояние, появляется сообщение об ошибке. Для клиентских -- ошибка показывается сразу, кнопка отправки остается заблокированной до исправления.
8. Сценарии использования как user flow
Use Case из раздела 10 спецификации -- готовый user flow для Figma. Основной поток -- это happy path, альтернативные потоки -- error states и edge cases.
Пример: Оформление заказа (Use Case из спецификации)
Happy path: Покупатель открывает оформление (UI-001) -> видит список товаров с ценами -> вводит адрес доставки -> нажимает "Оформить заказ" -> видит подтверждение (UI-002).
Error states для того же flow:
- Корзина пуста (BR-1) -> inline-ошибка ORDER_EMPTY на UI-001 -> покупатель возвращается в корзину
- Товар закончился -> banner ORDER_ITEM_OUT_OF_STOCK на UI-001 -> покупатель убирает товар
- Сервис каталога недоступен -> banner CATALOG_SERVICE_UNAVAILABLE -> кнопка "Повторить"
Каждый альтернативный поток из спецификации -- это отдельный экран или состояние экрана в Figma. Дизайнер строит flow-диаграмму, где каждый узел -- экран или состояние, а каждое ребро -- действие пользователя или ошибка системы.
9. Дизайн-система и DDD
Доменные объекты из раздела 3 спецификации маппятся на компоненты UI. Каждый агрегат, сущность и Value Object становится переиспользуемым компонентом в дизайн-системе.
| Доменный объект | Компонент UI | Где используется |
|---|---|---|
| Order | OrderCard | UI-003 (список), UI-004 (карточка) |
| OrderItem | ProductRow | UI-001 (таблица позиций), UI-002, UI-004 |
| OrderStatus | StatusBadge | UI-003, UI-004, UI-005 |
| Money | PriceLabel | Везде, где отображается сумма |
| DeliveryAddress | AddressForm (ввод) / AddressBlock (вывод) | UI-001 (форма), UI-004 (просмотр) |
| ProductSnapshot | ProductInfo | UI-001, UI-004 (название и артикул товара) |
StatusBadge -- один компонент с шестью вариантами (по количеству статусов). PriceLabel всегда показывает сумму в формате "7 320 руб." с разделителем тысяч. AddressForm включает валидацию (индекс -- 6 цифр, телефон -- маска). Эти компоненты создаются один раз и переиспользуются на всех экранах.
10. Мобильный vs веб
Реестр экранов (раздел 11) фиксирует платформу для каждого экрана.
Обе платформы (web + mobile): UI-001 (Оформление заказа), UI-002 (Подтверждение), UI-003 (Список заказов), UI-004 (Карточка заказа). Для мобильной версии: таблица позиций становится списком карточек, форма адреса -- отдельным шагом (wizard), кнопки действий уходят в нижнюю панель.
Только веб: UI-005 (Панель менеджера). Менеджер работает с большим объемом заказов, ему нужна таблица с фильтрами и сортировкой -- это десктопный сценарий. На мобильном устройстве менеджерский интерфейс не предусмотрен.
При проектировании мобильной версии учитывать: адаптивная таблица позиций (collapse колонок на узком экране), размер кнопок (минимум 44x44 pt для тач-зон), модальные окна ошибок заменяются на bottom sheet.