Создание системы бизнес-правил. Часть 5
Барбара фон Халле
Начало в выпусках: #142, #143, #144, #145, #146
От общего к частному
Общую методологию проектирования реляционных баз данных полезно рассматривать как структуру, помогающую делать выводы в мире правил. Сначала логическая модель данных переводится в продукт - независимый проект. Это первичная разработка базы, которая сохраняет структуру и цельность логической модели данных. Обеспечивая преимущества реляционной технологии: простоту, производительность и гибкость, она дает независимость от выбранной СУРБД.
Затем первичную разработку адаптируют к среде конкретного пакета и, наконец, настраивают в соответствии с нужной функциональностью и рабочими требованиями.
Подобным образом общая методология разработки правил переводит логическую модель правил в продукт - независимый проект, предназначенный для реализации модуля правил в системе. Это первичная разработка правил. Сохраняя отношения и цельность логической модели правил, она дает преимущества метода бизнес-правил: простоту, производительность и гибкость.
Затем первичная разработка правил адаптируется к среде пакета.
Целевая технология может быть не ориентирована на правила. Для контроля за исполнением правил (извне или изнутри СУБД) можно написать программный код общего пользования. Главная роль здесь принадлежит проектировщикам баз данных. Вам нужна хорошо управляемая автоматизация правил, которая гарантирует отсутствие избыточности и непоследовательности.
Наконец, разработку правил настраивают в соответствии с нужной функциональностью и рабочими требованиями.
Следует помнить, что оценивать проект будут не только по рабочим показателям и степени соответствия текущей ситуации на предприятии. Как правило, успешность определяется тем, насколько легко проект адаптируется к изменениям и будущим потребностям.
Преимущество технологии реляционных баз данных - способность трансформировать базы данных. Преимущество метода бизнес-правил - умение изменять правила (логику деловой политики).
Этапы разработки правил
Цель разработки - встроить модуль правил в архитектуру системы. Этот процесс включает, по меньшей мере, четыре момента: рабочие спецификации функций правил; привязку правил к уровню системы; подробные спецификации реализации каждого правила на целевом уровне; схему сообщения всех уровней с модулем правил.
Этап 1. Сохраните свою архитектуру, но усильте ее модулем правил. Без сомнения, трехъярусная архитектура (уровень представления, уровень бизнес-логики и уровень данных) по многим причинам предпочтительнее традиционной двухъярусной.
Применение метода правил требует смотреть глубже. В частности, нужно признать, что уровень бизнес-логики может фактически содержать два вида функциональности.
Традиционная функциональность управляет конкретным потоком процессов целевого приложения. Новая функциональность - это модуль или уровень, который управляет исполнением общих правил от имени приложений, аналогично уровню, который регулирует доступ к данным общего пользования.
Этап 2. Определите базовые требования для уровня правил, функциональные и технические.
Существуют два основных вида модулей правил: с ориентацией на данные и с ориентацией на обслуживание.
В модулях первого вида компонент правил реагирует на обращение приложения к данным, которые регулируются правилами. При попытке обновить информацию модуль правил проверяет истинность условий для данных и условий, которые должны быть поводом для реакции.
В модуле другого вида компонент правил реагирует на запрос активного приложения, а не просто на активацию данных. Приложение передает информацию службе правил, которая выполняет правила и отправляет результат обратно приложению. Затем приложение может прервать транзакцию, обновить базу или совершить другое действие.
Вполне возможно, в вашей системе пригодятся разные виды модулей правил.
Продолжение в следующем выпуске.