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