DDD-спецификация: гайд для бизнес-аналитика
Как бизнес-аналитику заполнять DDD-спецификацию.
DDD гайд бизнес-аналитик: введение
DDD гайд бизнес-аналитик — бизнес-аналитик -- ключевой участник создания DDD-спецификации. Именно БА переводит язык бизнеса в структурированное описание, которое затем используют архитекторы, разработчики и тестировщики. Этот документ собирает все рекомендации для БА из Шаблона спецификации и организует их по логическим темам.
Перед тем как сесть заполнять спеку — проведите Event Storming. Это workshop, на котором команда вместе с бизнесом за 4-8 часов выявляет события, акторов, бизнес-правила, агрегаты и границы контекстов. Каждый артефакт workshop ложится в конкретный раздел этой спеки. Без Event Storming БА оказывается в позиции «один разрабатываю спеку у себя в голове» — и через месяц обнаруживается, что архитектор и разработчики «понимали по-другому».
Задача БА -- описать предметную область понятным языком, без технических деталей. Архитектурные паттерны, код, инфраструктура -- зона ответственности других ролей. БА отвечает за бизнес-смысл, терминологию, правила и сценарии.
Все примеры ниже используют домен "Интернет-магазин: оформление заказа".
1. Как определить границы контекста
Bounded Context -- это граница ответственности вашей задачи. Представьте, что вся компания -- большой город, а контекст -- один район со своими правилами.
Что делать:
- Описать, какой бизнес-процесс или функциональную область вы описываете
- Зафиксировать значение ключевых терминов именно в вашем контексте. Одно и то же слово (например, "заказ") может означать разное в разных контекстах
- Указать, откуда вы получаете данные и кому отдаете результат
- Не описывать типы связей (ACL, OHS) -- это работа архитектора. Достаточно сказать: "мы получаем данные из системы X" и "мы отдаем результат в систему Y"
Диаграмма C1 (System Context) -- это "вид сверху" на систему. БА может нарисовать её вместе с архитектором.
2. Как собрать и вести глоссарий
Глоссарий -- самый важный артефакт для БА в DDD. Это словарь проекта, где бизнес, аналитики и разработчики договариваются называть вещи одинаково.
Суть: если бизнес говорит "заявка", разработчик пишет в коде Request, а в базе лежит order -- это путь к ошибкам.
Что делать:
- Собрать термины у доменных экспертов
- Зафиксировать значение каждого термина в контексте вашего Bounded Context
- Определить "антислова" -- какие термины не используем и чем их заменяем
- Следить, чтобы все участники проекта использовали одни и те же слова
Пример: "Позиция заказа" -- конкретный товар в заказе с количеством и ценой. Одна позиция = один SKU. Не "строка заказа", не "элемент заказа".
3. Как описать объекты предметной области
Для БА доменная модель -- это ключевые объекты и связи между ними. Не нужно вникать в агрегаты и Value Objects -- это технические детали.
Что делать:
- Перечислить главные объекты: "Заказ", "Позиция заказа", "Адрес доставки", "Итоговая сумма"
- Для каждого объекта перечислить свойства, важные для бизнеса
- Указать ограничения: количество товара 1--99, сумма не может быть отрицательной, индекс -- 6 цифр
Пример: у заказа есть позиции, адрес доставки и итоговая сумма. У позиции -- товар, количество и цена на момент заказа. Если цена в каталоге изменится, в заказе останется старая.
4. Как описать жизненный цикл объектов
Жизненный цикл -- это "карта жизни" объекта: все его состояния и переходы между ними.
Что делать:
- Перечислить все состояния (статусы): создан, подтвержден, оплачен, отправлен, доставлен, отменен
- Для каждого перехода указать: кто может его выполнить и при каких условиях
- Отметить запрещенные переходы: отмена возможна только до оплаты, после оплаты -- только возврат через администратора
- Отдельно отметить "тупики" -- состояния, из которых нельзя выйти (доставлен, отменен)
Пример: Заказ: создан -> подтвержден -> оплачен -> отправлен -> доставлен. Отмена возможна из "создан" и "подтвержден". После оплаты -- только возврат.
5. Как составить ролевую модель
Перечислите, кто работает с системой и что каждый может делать. Для каждого действия из раздела "Команды" должно быть понятно, какая роль его выполняет.
Что делать:
- Перечислить все роли: Покупатель, Менеджер, Администратор
- Для каждой роли указать: что может делать, что не может, какие ограничения
- Составить матрицу "роль x действие"
Пример: Покупатель видит и управляет только своими заказами. Менеджер видит заказы своего региона. Администратор имеет полный доступ, включая возврат.
6. Как формулировать бизнес-правила с кодами BR
Бизнес-правила -- это ограничения, которые система должна гарантировать всегда.
Что делать:
- Записывать правила простым языком: "Заказ не может быть пустым", "Нельзя отменить оплаченный заказ"
- Давать каждому правилу уникальный код:
BR-1,BR-2и т.д. На эти коды будут ссылаться все остальные разделы - Для каждого правила описать, что должна сделать система при нарушении
Пример: BR-4 -- Отменить заказ можно только в статусе CREATED или CONFIRMED. При нарушении -- ошибка "Нельзя отменить оплаченный заказ", покупателю предлагается обратиться к администратору.
7. Как описать действия пользователей -- команды
Команды -- это ответ на вопрос "что пользователь может СДЕЛАТЬ?". Создать заказ, добавить товар, подтвердить, отменить, инициировать возврат.
Что делать:
- Для каждого действия описать: кто выполняет (роль), какие данные вводит
- Указать, какие бизнес-правила проверяются (ссылки на BR)
- Описать, что происходит в случае успеха и ошибки
- Связать команду с экраном, где она вызывается
Пример: "Создать заказ" -- Покупатель указывает товары и адрес доставки. Проверяются BR-1 (не пустой), BR-2 (количество 1--99), BR-3 (сумма >= 1 руб.). При успехе заказ создается в статусе CREATED.
8. Как определить события и уведомления
События -- это ответ на вопрос "о чем система должна СООБЩИТЬ, когда что-то случилось?".
Что делать:
- Для каждого важного факта описать: что произошло, кого уведомить, какие процессы запустить
- Формулировать на бизнес-языке, без технических деталей
Пример: "Когда заказ оплачен, система должна создать заявку на доставку и отправить чек покупателю." "Когда заказ отменен, система должна снять резерв на складе и уведомить покупателя."
9. Как описать экраны и отчеты
Экраны и запросы -- это то, что пользователи хотят ВИДЕТЬ в системе: списки, карточки, дашборды.
Что делать:
- Описать, какой экран нужен, какие данные отображаются
- Указать фильтры и сортировку
- Зафиксировать, кто имеет доступ к экрану
- Описывать экраны на привычном языке -- главное зафиксировать что на экране и какие действия доступны, а не пиксели
Пример: экран "Список заказов" -- показывает номер, статус, количество позиций, сумму и дату. Фильтр по статусу и дате. Покупатель видит только свои, менеджер -- заказы своего региона.
10. Как писать сценарии использования
Use Case -- это пошаговый сценарий: кто действует, что хочет, какие шаги проходит, что может пойти не так, каков результат.
Что делать:
- Указать актора (роль), предусловия и экран
- Описать основной поток шаг за шагом, используя термины из глоссария
- Ссылаться на BR (бизнес-правила), команды и запросы
- Описать альтернативные потоки: что происходит при ошибке
Пример основного потока: Покупатель переходит к оформлению -> видит товары с ценами -> вводит адрес -> нажимает "Оформить заказ" -> система проверяет BR-1, BR-2, BR-3 -> заказ создан -> покупатель видит подтверждение. Альтернатива: корзина пуста -> ошибка ORDER_EMPTY -> покупатель возвращается в корзину.
11. Как описать сложные процессы простым языком
Сложные процессы (Saga) затрагивают несколько систем. Задача БА -- описать их на бизнес-языке, без технических деталей оркестрации.
Что делать:
- Описать последовательность шагов: "Когда заказ подтвержден, нужно зарезервировать товар, провести оплату и создать заявку на доставку"
- Указать, что делать при ошибке на каждом шаге: "Если оплата не прошла -- резерв отменить"
- Описать отдельные процессы отдельно
Пример: Возврат -- отдельный процесс. Администратор инициирует возврат, система возвращает деньги через платежный шлюз и (при необходимости) возвращает товар на склад.
12. Как составить каталог ошибок на человеческом языке
Для каждой ошибки нужен текст, который увидит пользователь. Задача БА -- перевести технические сообщения на человеческий язык и описать, что делать дальше.
Что делать:
- Для каждой ошибки написать понятное сообщение
- Указать, при каких условиях возникает ошибка (ссылка на BR)
- Описать рекомендуемое действие пользователя
Пример: ошибка ORDER_CANCEL_FORBIDDEN -- сообщение "Нельзя отменить оплаченный заказ". Действие: "Обратитесь к администратору для оформления возврата". Ошибка CATALOG_SERVICE_UNAVAILABLE -- "Не удалось получить данные о товарах, попробуйте позже". Действие: повторить через 1--2 минуты.
13. Как описать интеграции на уровне бизнес-процесса
Интеграции -- это точки обмена данными с другими системами. БА описывает их на уровне бизнес-процесса, без технических деталей протоколов.
Что делать:
- Указать, что передается: какие данные, откуда и куда
- Описать, что делать, если связь потеряна
Пример: "Мы запрашиваем цены и наличие товаров из Каталога. Мы отправляем информацию об оплаченных и отмененных заказах в Доставку. Если Каталог недоступен -- показываем пользователю сообщение 'попробуйте позже'."
14. Как писать критерии приемки
Критерии приемки -- это конкретные проверяемые утверждения в формате Given/When/Then.
Что делать:
- Формулировать конкретно и проверяемо
- Избегать расплывчатых формулировок вроде "система работает корректно" -- это не критерий
- Ссылаться на экраны, команды, бизнес-правила и ошибки
Пример: Given -- покупатель авторизован, заказ в статусе PAID. When -- пытается отменить заказ. Then -- ошибка ORDER_CANCEL_FORBIDDEN, статус не изменился, предложение обратиться к администратору для возврата.
15. Как задать нефункциональные требования в цифрах
Нефункциональные требования -- это ожидания от системы, выраженные в конкретных цифрах.
Что делать:
- Указать скорость: "Страница оформления заказа открывается не дольше 2 секунд"
- Указать доступность: "Система работает 24/7, кроме плановых обновлений по ночам"
- Указать нагрузку: "В период распродаж нагрузка вырастает в 5 раз -- система должна выдержать"
- Указать объемы: сколько заказов в год, сколько пользователей одновременно
Пример: до 10 000 покупателей онлайн, до 1 000 000 заказов в год, пятикратный рост в Black Friday. Активные заказы хранятся бессрочно, завершенные -- 3 года.