Объекты предметной области

После словаря появляется вопрос: какие понятия заслуживают отдельного представления в предметной модели? В предметной области встречаются люди, документы, заявки, заказы, платежи, события, справочники, роли, статусы и отчёты. Не все они одинаково важны для поведения системы.

Кандидаты в предметные объекты

Кандидата в объект стоит проверять вопросами:

есть ли у него идентичность;
может ли он существовать независимо от других объектов;
есть ли у него жизненный цикл;
связаны ли с ним бизнес-правила;
нужно ли системе хранить или передавать сведения о нём;
есть ли операции, которые меняют его состояние;
участвует ли он в сценариях или процессах.

Например, “заказ” обычно имеет идентичность, позиции, статус, правила оплаты и доставки, историю изменений. Это сильный кандидат. “Цвет кнопки” может быть важен для интерфейса, но не является предметным объектом. “Срочность” может быть не классом, а атрибутом заявки или элементом справочника. “Менеджер” может быть ролью пользователя, а не отдельным классом, если система не моделирует сотрудников как предметные объекты.

Источники и роли понятий

Типовые источники объектов:

Источник	Что можно найти
Требования	результаты функций, основные данные
Сценарии	создаваемые и проверяемые объекты
Процессы	документы, события, статусы, передачи данных
Бизнес-правила	объекты, на которые накладываются ограничения
Словарь	устойчивые предметные термины
Отчёты	агрегированные данные и показатели

Объекты также выявляются через процессные потоки. То, что создаётся, проверяется, согласуется, отправляется, оплачивается, закрывается или архивируется, часто заслуживает отдельного анализа. Особенно важны объекты с состояниями: заявка, заказ, платёж, документ, инцидент, бронь, поставка.

После проверки нужно выбрать роль понятия в предметной модели:

Кандидат	Возможная роль
Заявка	класс или объект с жизненным циклом
Статус заявки	атрибут, перечисление или отдельный справочник
Подтверждение	событие, документ или операция
Дата создания	атрибут
Проверить заявку	операция или шаг процесса
Согласующий	роль пользователя или связь с сотрудником

Особые случаи

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

Особенно осторожно нужно относиться к ролям и людям. “Пользователь” часто является техническим или организационным понятием, а “студент”, “преподаватель”, “оператор” — предметными ролями. В одной системе достаточно роли доступа, в другой нужно моделировать самого сотрудника, его подразделение, полномочия и историю действий. Решение зависит от требований и правил.

Ещё один частый случай — документы и события. Документ обычно имеет содержимое, автора, дату, статус и правила изменения. Событие фиксирует факт, произошедший во времени: заявка подана, платёж подтверждён, запись отменена. Иногда событие не нужно хранить как отдельный объект, иногда без него невозможно построить аудит и отчётность.

Выбранные объекты и их роли становятся основой концептуальной модели и затем фиксируются на концептуальной диаграмме классов и объектов. При этом классификатор, объект, атрибут и роль не следует отождествлять автоматически — их свойства разобраны в материале о классификаторах, именах и пространствах имён.