Предметная область, словарь и бизнес-правила

Предметная область

Предметная область — это часть реальности, с которой работает информационная система. Она включает людей, документы, процессы, события, данные, правила и ограничения, существующие независимо от конкретного программного решения.

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

Анализ предметной области отвечает на несколько вопросов:

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

Эта работа нужна до построения детальных UML-диаграмм. Если не договориться о смысле предметных понятий, на диаграммах быстро появятся разные названия для одного и того же объекта или, наоборот, одно название для разных сущностей.

Словарь предметной области

Словарь предметной области фиксирует термины, которыми пользуются участники проекта. Это не технический глоссарий фреймворка, а словарь языка предметной области.

Минимальная запись словаря может включать:

Поле	Содержание
Термин	основное название понятия
Определение	что означает термин в рамках системы
Синонимы	другие варианты названия, если они есть
Источник	документ, интервью, регламент, эксперт
Пример использования	короткая фраза или ситуация
Связанные правила	бизнес-правила, которые относятся к термину
Связанные сценарии	use cases или шаги процесса, где термин используется

Словарь помогает не смешивать предметные и технические понятия. Например, “заявка” может быть предметным объектом, а RequestDto - техническим классом передачи данных. Оба элемента могут быть связаны, но их нельзя считать одним и тем же понятием.

Способы выявления терминов в словаре предметной области рассматриваются отдельно.

Бизнес-правила

Бизнес-правило описывает ограничение или условие предметной области. Оно отвечает не на вопрос “что должна уметь система”, а на вопрос “что в этой предметной области считается допустимым”.

В отличие от требования, бизнес-правило не назначает системе обязанность напрямую. Оно фиксирует норму предметной области. Требование появляется тогда, когда мы решаем, что проектируемая система должна это правило контролировать, учитывать или использовать при выполнении сценария.

Примеры бизнес-правил:

заказ нельзя отгрузить до оплаты;
студент не может записаться на две пары, которые проходят в одно время;
заявка после утверждения не редактируется исполнителем;
скидка применяется только к активному договору;
врач не принимает пациентов вне своего расписания.

Бизнес-правила могут проявляться в разных артефактах модели:

как защитные условия на диаграмме деятельности;
как ограничения на диаграмме классов;
как условия переходов на диаграмме состояний;
как предусловия и постусловия в спецификации варианта использования;
как проверки в технической модели.

Важно отделять бизнес-правило от способа его реализации. Правило “заказ нельзя отгрузить до оплаты” не означает, что в системе обязательно должен быть метод checkPaymentBeforeShipping(). Техническая реализация появится позже, а на аналитическом уровне нужно зафиксировать саму предметную норму.

Например, правило “студент не может записаться на две пары, которые проходят в одно время” само по себе описывает устройство учебного процесса. Функциональное требование на его основе может звучать так: “система должна запрещать запись студента на занятие, если оно пересекается по времени с уже выбранным занятием”. Нефункциональное требование может дополнить его ограничением по скорости проверки, а диаграммы покажут, где именно это правило влияет на сценарий и состояние объектов.

Место предметной области в проектировании ИС

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

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