Придумал хорошую метафору или, скорее, аналогию причине, почему business rules engines зло (ибо не работают). Или работают, но с большим геморроем. (Работал с Drools и самописными надстройками.)
Идея, стоящая за business rules engines - дать пользователю самому править бизнес-логику. Без цепочки посредников "аналитик-программист-тестер".
Почему математики стараются обойтись минимумом аксиом при формализации новой теории? Потому что, если окажется, что всего лишь одна аксиома лишняя, некорректная, усложняет систему или приводит к противоречивым выводам - то попытки ее удалить потребуют пересмотра всей формальной теории и приложения усилий, сравнимых с построением формальной системы с нуля. И хорошо, если не окажется, что теория не рассыпалась, или что мы не удаляем не ту аксиому. Проще и очевиднее база - надежнее здание. Для программирования весьма актуально.
При добавлении новых бизнес-правил сложно думать о совместимости с существующими. И аксиом (как правило) никаких нет в явном виде. И формулы на бумажке не факт что расписывали. Новые требования обычно высказываются уже в очень high-level виде: то, что нужно увидеть в итоге. Сложно заметить, что новое правило противоречит вон тем трем (из тысячи), добавленным совсем другим человеком 4 года назад.
Обычно пользователь махнет рукой и скажет "вроде должно быть так, добавляем". Нету посредников. Нет программиста, который потенциально может завернуть заметное (для него) некорректное требование, сказав "вы уверены, что хотите именно этого?"
В принципе, программисты работают так же - прикидывают на пальцах, потом машут рукой и имплементят. А потом надеются отловить ошибки тестами на разных уровнях, полагаются на компилятор, абстракции или статическую типизацию. Но фильтров между идеей и результатом больше. Заказчик - BA - программист - QA - UAT.
Идея, стоящая за business rules engines - дать пользователю самому править бизнес-логику. Без цепочки посредников "аналитик-программист-тестер".
Почему математики стараются обойтись минимумом аксиом при формализации новой теории? Потому что, если окажется, что всего лишь одна аксиома лишняя, некорректная, усложняет систему или приводит к противоречивым выводам - то попытки ее удалить потребуют пересмотра всей формальной теории и приложения усилий, сравнимых с построением формальной системы с нуля. И хорошо, если не окажется, что теория не рассыпалась, или что мы не удаляем не ту аксиому. Проще и очевиднее база - надежнее здание. Для программирования весьма актуально.
При добавлении новых бизнес-правил сложно думать о совместимости с существующими. И аксиом (как правило) никаких нет в явном виде. И формулы на бумажке не факт что расписывали. Новые требования обычно высказываются уже в очень high-level виде: то, что нужно увидеть в итоге. Сложно заметить, что новое правило противоречит вон тем трем (из тысячи), добавленным совсем другим человеком 4 года назад.
Обычно пользователь махнет рукой и скажет "вроде должно быть так, добавляем". Нету посредников. Нет программиста, который потенциально может завернуть заметное (для него) некорректное требование, сказав "вы уверены, что хотите именно этого?"
В принципе, программисты работают так же - прикидывают на пальцах, потом машут рукой и имплементят. А потом надеются отловить ошибки тестами на разных уровнях, полагаются на компилятор, абстракции или статическую типизацию. Но фильтров между идеей и результатом больше. Заказчик - BA - программист - QA - UAT.
-
-
15.07.2013 в 12:21Эту модель придумали маркетологи чтобы продать заказчику? "Теперь ты главный и рулишь"
Или программеры? "Да ты достал уже, давай сам теперь"