Объекты предметной области
После словаря появляется вопрос: какие термины должны стать объектами модели? В предметной области встречаются люди, документы, заявки, заказы, платежи, события, справочники, роли, статусы и отчёты. Но механический принцип “все существительные — классы” даёт плохие модели.
Кандидата в объект стоит проверять вопросами:
- есть ли у него идентичность;
- может ли он существовать независимо от других объектов;
- есть ли у него жизненный цикл;
- связаны ли с ним бизнес-правила;
- нужно ли системе хранить или передавать сведения о нём;
- есть ли операции, которые меняют его состояние;
- участвует ли он в сценариях или процессах.
Например, “заказ” обычно имеет идентичность, позиции, статус, правила оплаты и доставки, историю изменений. Это сильный кандидат. “Цвет кнопки” может быть важен для интерфейса, но не является предметным объектом. “Срочность” может быть не классом, а атрибутом заявки или элементом справочника. “Менеджер” может быть ролью пользователя, а не отдельным классом, если система не моделирует сотрудников как предметные объекты.
Типовые источники объектов:
| Источник | Что можно найти |
|---|---|
| Требования | результаты функций, основные данные |
| Сценарии | создаваемые и проверяемые объекты |
| Процессы | документы, события, статусы, передачи данных |
| Бизнес-правила | объекты, на которые накладываются ограничения |
| Словарь | устойчивые предметные термины |
| Отчёты | агрегированные данные и показатели |
Объекты также выявляются через процессные потоки. То, что создаётся, проверяется, согласуется, отправляется, оплачивается, закрывается или архивируется, часто заслуживает отдельного анализа. Особенно важны объекты с состояниями: заявка, заказ, платёж, документ, инцидент, бронь, поставка.
Не каждый кандидат становится классом. Возможные решения:
| Кандидат | Возможная роль |
|---|---|
| Заявка | класс или объект с жизненным циклом |
| Статус заявки | атрибут, перечисление или отдельный справочник |
| Подтверждение | событие, документ или операция |
| Дата создания | атрибут |
| Проверить заявку | операция или шаг процесса |
| Согласующий | роль пользователя или связь с сотрудником |
Хороший объект предметной области помогает объяснить поведение системы. Если с объектом не связано ни данных, ни правил, ни состояний, ни сценариев, возможно, это просто слово из описания, а не элемент модели.
Особенно осторожно нужно относиться к ролям и людям. “Пользователь” часто является техническим или организационным понятием, а “студент”, “преподаватель”, “оператор” — предметными ролями. В одной системе достаточно роли доступа, в другой нужно моделировать самого сотрудника, его подразделение, полномочия и историю действий. Решение зависит от требований и правил.
Ещё один частый случай — документы и события. Документ обычно имеет содержимое, автора, дату, статус и правила изменения. Событие фиксирует факт, произошедший во времени: заявка подана, платёж подтверждён, запись отменена. Иногда событие не нужно хранить как отдельный объект, иногда без него невозможно построить аудит и отчётность.