В любой системе, которая имеет дело с реальным миром так или иначе присутствуют куча условий и ветвлений.

Например, нам приходят заказы. От разных контрагентов. Но контрагентов есть множество видов, и заказ каждого отдельного вида обрабатывается по отдельной логике.

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

Но бизнес приходит с новыми требованиями. Там, где раньше были только составные условия типа ИЛИ теперь появляются И и НЕ. Там, где была последовательная обработка всех правил по очереди, теперь появляются ветвления и дополнительные условия.

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

Ну и апофеозом этого дела будет встраивание скриптового языка (js/groovy и тд) в условия и действия. Цикл замкнулся. Поздравляю, ваш круд теперь тьюринг-полный.

Я наблюдал это и в больших проектах и в маленьких. Рано или поздно хардкода начинает не хватать, и разработка изобретает очередной велосипед, вначале беговел и потихоньку превращая это все дело в мотоцикл из безумного макса.

Готовых отчетов по данным не хватает, и вот аналитикам в руки уже дается база, SQL или BI-система куда разработчики сгружают подготовленные данные.

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