Uma Introdução ao Motor de Regras Drools

Este post de blog é a segunda parte de uma série sobre motores de regras de negócios. A Parte 1 cobriu motores de regras de negócios detalhadamente; o que são, como funcionam e por que você pode precisar de um. Este post oferece uma visão geral de alto nível sobre um motor de regras específico chamado Drools e como construir um sistema moderno de gestão de regras de negócios usando o Drools:

• Glossário básico do Drools

• Desafios com o Drools

• Pouco suporte para regras e dados relacionados que mudam frequentemente

• Redundância e gestão ineficiente de regras

• Expressividade limitada e curva de aprendizado íngreme

• Construindo um sistema moderno de gestão de regras de negócios baseado no Drools

• Conclusão

• Veja a Oscilar em ação, agende uma demonstração

O que é o Drools?

O Drools é uma biblioteca de regras com um motor de regras baseado em encadeamento progressivo e regressivo. Ele usa uma implementação aprimorada do algoritmo Rete e suporta o padrão Java Rules Engine API para o seu motor de regras.

Uma breve história

O Projeto Drools foi iniciado por Bob McWhirter em 2001 como um projeto do SourceForge. Em 2005, o Drools foi integrado ao JBoss como parte de sua oferta JEMS e renomeado para JBoss Rules. Em 2006, o próprio JBoss foi adquirido pela Red Hat e voltou a se chamar Drools em 2007.

Glossário básico do Drools

Aqui estão alguns dos conceitos básicos do Drools:

Drools Rule Language

A Drools Rule Language ou regras DRL são regras de negócios definidas em arquivos de texto .drl. Um arquivo DRL pode ter uma ou mais regras que definem as condições e ações da regra em um formato "quando-então" (when-then).

Regra

Uma Regra consiste em uma condição que dispara a regra (quando) e uma consequência que executa ações (então) quando ela é disparada. Ela associa fatos a ações correspondentes. Como mencionamos no artigo anterior, as regras de negócios só podem ser verdadeiras ou falsas.

Fatos

As regras de negócios são compostas por fatos, e os fatos representam os dados que servem de informação para as regras.

Memória de Trabalho (Working Memory)

A memória de trabalho é o armazenamento que contém os fatos. Ela permite que o motor de negócios use os fatos para correspondência de padrões. Os fatos também podem ser modificados, inseridos e removidos da memória de trabalho.

Base de Conhecimento (Knowledge Base)

A base de conhecimento é uma interface que gerencia uma coleção de regras, tipos internos e processos, representando o conhecimento do ecossistema Drools. As sessões de conhecimento são criadas a partir da base de conhecimento.

Sessão de Conhecimento (Knowledge Session)

A sessão de conhecimento contém todos os recursos necessários para disparar as regras. Os fatos são inseridos em uma sessão e, em seguida, as regras correspondentes são disparadas.

Podem existir sessões de conhecimento sem estado (stateless) e com estado (stateful).

As sessões sem estado recebem fatos ou uma memória de trabalho, o que significa que uma nova sessão é criada para cada requisição, enquanto as sessões com estado mantêm as sessões anteriores, continuando de onde a última parou.

Módulo

Um módulo contém várias bases de conhecimento, que ajudam a criar sessões de conhecimento.

Desafios com o Drools

Embora o Drools permita que você defina e gerencie as regras de negócios fora do seu código, ele também apresenta alguns desafios.

Pouco suporte para regras e dados relacionados que mudam frequentemente

O principal desafio do Drools é a falta de suporte para regras que mudam com frequência. Geralmente, uma aplicação Java baseada em Drools exige que todos os artefatos de regras, como DRLs e arquivos Excel de tabelas de decisão, façam parte do próprio binário da aplicação. Isso significa que os artefatos precisam estar no repositório de código-fonte ou ser extraídos dele durante o processo de compilação da aplicação. Isso se torna trabalhoso com regras que mudam constantemente; cada alteração de regra exige adicionar ou modificar os artefatos de regras, compilar o código da aplicação e implantar nos servidores de produção.

A regra DRL usa objetos de dados Java para recuperar fatos ou um conjunto de resultados. Assim como as regras DRL, a criação e o uso de novos objetos de dados também exigem modificação do código e implantação. Como resultado, o Drools costuma funcionar bem com um conjunto de dados estático em vez de dinâmico. No entanto, a maioria dos casos de uso reais exige conjuntos de dados dinâmicos para tomadas de decisão precisas. Por exemplo, a maioria das decisões de invasão de conta exige dados multidimensionais sobre o histórico de atividades e ações recentes do usuário, que mudam rapidamente nos bastidores.

Essa dependência do código — e a compilação e implantação resultantes — tanto para as regras quanto para os dados relacionados, reduz significativamente a velocidade de iteração das tomadas de decisão.

Além de limitar sua eficácia na resolução de problemas do mundo real, isso também atrasa o tempo de resposta para as decisões de negócios.

Redundância e gestão ineficiente de regras

As mesmas regras de negócios podem se aplicar a diferentes aplicações e serviços, levando a redundâncias e desafios de governança. O Drools impõe ao usuário a tarefa de manter as regras e os arquivos DRL sincronizados. Isso exige a construção de ferramentas para gerenciar as regras em um repositório de código-fonte, juntamente com um serviço de regras que gerencia atualizações e distribui as regras, o que demanda propriedade e manutenção de um serviço centralizado de regras. Além disso, o serviço de regras precisa testar e avaliar os possíveis efeitos colaterais de cada alteração de regra, o que por si só gera um trabalho significativo para o usuário do Drools.

Expressividade limitada e curva de aprendizado íngreme

O Drools possui sua própria DSL baseada em Java com uma curva de aprendizado considerável, enquanto a maioria da comunidade de ciência de dados tem formação em Python. A DSL do Drools também é limitada em seu poder expressivo. Por exemplo, o Drools tem suporte limitado para algumas funções matemáticas comuns, como fatoriais e máximo divisor comum, que são úteis na prática. Para resolver esse desafio, o Drools permite o desenvolvimento de "DSLs personalizadas", mas, novamente, elas são limitadas pelo suporte de regras subjacente.

Construindo um sistema moderno de gestão de regras de negócios baseado no Drools

Compreendendo os desafios impostos pelo Drools, vamos ver o que falta nele para facilitar a sua aplicação prática:

• Banco de Dados de Regras: Uma forma de armazenar todas as regras fora do binário da aplicação, em um sistema externo, como um banco de dados.

• Serviço de Regras: Um serviço de regras com uma API REST que reconstrói programaticamente os objetos do Drools com base nas alterações das regras, eliminando a necessidade de modificar o código. Esse serviço de regras também deve permitir implementar novas alterações nas regras rapidamente, sem implantar ou reiniciar as aplicações. Portanto, ele deve integrar a gestão de código-fonte das regras a um fluxo de CI/CD para enviar as alterações para o banco de dados central de regras.

• Banco de Dados de Conhecimento ou de Features: Uma forma de integrar dados de features de ferramentas de terceiros, bancos de dados, data lakes e outras aplicações em um banco de dados centralizado de features, eliminando a necessidade de armazenar todos os fatos que as regras usam em memória e viabilizando a realização de testes retroativos (backtesting) de novas alterações de regras.

• Serviço de Features: Uma base de conhecimento central ou serviço de features com uma API REST que aceita features ou fatos em um formato comum e responde com os dados necessários para as regras.

• Análise de Regras: Gestão e monitoramento centralizados das regras para avaliar seu desempenho ao longo do tempo e saber quando atualizá-las.

• Implantação Canário (Canary Rollout): Qualquer uso prático de um motor de regras em produção exige uma implementação cuidadosa das novas regras. Esse processo começa com o teste retroativo das regras em dados passados, seguido pela implantação da regra em modo sombra (shadow mode) e, por fim, por uma implantação canário gradual antes de processar 100% dos dados disponíveis.

• Automação Sem Código (No-code): Uma interface que permite que analistas de negócios e qualquer pessoa que não seja desenvolvedora atualizem facilmente as regras com base em novos sinais e casos de uso, sem precisar escrever código.

Como deve estar claro pela descrição acima, construir um sistema moderno de gestão de regras de negócios — ou motor de decisão — é um projeto de grande porte que exige profunda especialização.

Conclusão

O Drools é uma abstração boa, porém de baixo nível, para um motor de regras, e não um sistema moderno de gestão de regras de negócios. Sendo assim, ele exige a construção de inúmeros recursos para se transformar em uma solução completa de tomada de decisão.

A Oscilar é um motor de decisão moderno, sem código e em tempo real. Ela automatiza a criação de fatos ou features personalizadas, enriquecimento e análise, combinada com um motor de regras que executa regras de forma síncrona ou assíncrona, e oferece uma interface fácil de usar para ir de uma nova feature a uma nova regra em minutos.