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

• Glossário básico do Drools

• Desafios com Drools

• Suporte fraco para regras e dados relacionados que mudam frequentemente

• Redundância e gestão ineficiente de regras

• Expressividade limitada e curva de aprendizado acentuada

• Construindo um sistema moderno de gerenciamento de regras de negócios baseado em Drools

• Conclusão

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

O que é Drools?

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

Uma breve história

O Projeto Drools foi iniciado por Bob McWhirter em 2001 como um projeto no SourceForge. Em 2005, Drools foi integrado ao JBoss como parte da oferta JEMS e rebatizado como JBoss Rules. Em 2006, o próprio JBoss foi adquirido pela Red Hat e foi renomeado para Drools em 2007.

Glossário básico do Drools

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

Linguagem de Regras Drools

A Linguagem de Regras Drools 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 uma forma quando-então.

Regra

Uma Regra consiste em uma condição que dispara a regra (quando) e uma consequência que executa ações (então) quando é disparada. Associa fatos com ações correspondentes. Como mencionamos no blog 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 dados que servem como informações para as regras.

Memória de Trabalho

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

Base de Conhecimento

A base de conhecimento é uma interface que gerencia uma coleção de regras, tipos internos e processos e representa o conhecimento do ecossistema Drools. Sessões de conhecimento são criadas usando a base de conhecimento.

Sessão de Conhecimento

A sessão de conhecimento mantém todos os recursos necessários para disparar regras. Fatos são inseridos em uma sessão, e então regras correspondentes são disparadas.

Podem existir sessões de conhecimento sem estado e com estado.

Sessões de conhecimento sem estado têm fatos ou uma memória de trabalho inseridos nelas, e significa que uma nova sessão é criada para cada solicitação, enquanto sessões de conhecimento com estado mantêm as sessões antigas, continuando de onde a anterior parou.

Módulo

Um módulo contém múltiplas bases de conhecimento, que ajudam a criar sessões de conhecimento.

Desafios com Drools

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

Suporte fraco para regras e dados relacionados que mudam frequentemente

O principal desafio com Drools é a falta de suporte para regras que mudam frequentemente. Geralmente, uma aplicação Java baseada em Drools exige que todos os artefatos de regras, como DRLs, arquivos excel de tabelas de decisão, façam parte do próprio binário da aplicação. Isso significa que os artefatos devem estar presentes no repositório de código-fonte ou serem puxados dele durante o processo de build da aplicação. Isso se torna complicado com regras que mudam frequentemente; cada mudança de regra exige adicionar ou modificar os artefatos de regras, construir o código da aplicação e implantar nos servidores de produção.

As regras DRL usam objetos de dados Java para recuperar fatos ou um conjunto de resultados. Como as regras DRL, criar e usar novos objetos de dados também exige modificação de código e implantação. Como resultado, Drools geralmente funciona bem com um conjunto de dados estático em vez de um conjunto de dados dinâmico. No entanto, a maioria dos casos de uso no mundo real exige conjuntos de dados dinâmicos para decisões precisas. Por exemplo, a maioria das decisões de aquisição de conta exigem dados multidimensionais sobre o histórico de atividades do usuário e ações recentes, que por si só estão mudando rapidamente nos bastidores.

Essa dependência de código — e o consequente build e implantação — tanto para regras quanto para os dados relacionados, diminui significativamente a velocidade de iteração de tomada de decisão.

Além de limitar sua eficácia para resolver problemas do mundo real, isso também reduz o tempo de resposta para decisões de negócios.

Redundância e gestão ineficiente de regras

As mesmas regras de negócios podem se aplicar a diferentes aplicativos e serviços, levando à redundância e desafios de governança. Drools impõe ao usuário o ônus de manter as regras e os arquivos DRL em sincronia. Isso exige a construção de ferramentas para gerenciar regras em um repositório de código-fonte junto com um serviço de regras que gerencia atualizações e serve regras, exigindo propriedade e manutenção de um serviço centralizado de regras. Além disso, o serviço de regras deve testar e avaliar possíveis efeitos colaterais de cada mudança de regra, o que por si só impõe um fardo significativo ao usuário de Drools.

Expressividade limitada e curva de aprendizado acentuada

O Drools tem seu próprio DSL baseado em Java, com uma curva de aprendizado não trivial, enquanto a maioria da comunidade de ciência de dados possui um background em Python. O DSL do Drools também é limitado em sua capacidade expressiva. Por exemplo, o Drools tem suporte limitado para algumas funções matemáticas comuns como fatoriais, maior divisor comum, que são úteis na prática. Para enfrentar esse desafio, o Drools permite o desenvolvimento de "DSLs personalizados", mas, novamente, são limitadas pelo suporte de regras subjacente.

Construindo um sistema moderno de gerenciamento de regras de negócios baseado em Drools

Dada a compreensão dos desafios impostos pelo Drools, vejamos o que está faltando no Drools para tornar mais fácil a aplicação pragmática do Drools:

• Banco de Regras: Um modo 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 objetos Drools com base nas mudanças nas regras, eliminando assim a necessidade de modificar o código. Esse serviço de regras também deve permitir a implementação rápida de novas mudanças de regras sem implantar ou reiniciar aplicativos. Assim, deve construir a gestão do código-fonte de regras acoplada a um pipeline CI/CD para empurrar mudanças para o banco de dados central de regras.

• Base de Conhecimento ou Banco de Recursos: Um modo de integrar dados de características entre ferramentas de terceiros, bancos de dados, data lakes e outros aplicativos em um banco de dados de características central, eliminando a necessidade de armazenar todos os fatos que as regras usam em memória e potencializando a capacidade de realizar backtesting de novas mudanças de regras.

• Serviço de Recursos: Uma base de conhecimento central ou serviço de recursos com uma API REST que aceita características ou fatos em um formato comum e responde com quaisquer dados exigidos pelas regras.

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

• Implementação Gradual: Qualquer uso prático de um motor de regras em produção requer uma implementação cuidadosa de novas regras. Esse processo começa com o backtesting das regras em dados passados, seguido pela implantação da regra no modo sombra, seguido por uma implementação gradual da regra antes de processar 100% dos dados disponíveis.

• Automação sem Código: Uma interface que permite a analistas de negócios e outros não desenvolvedores evoluir facilmente regras com base em novos sinais e casos de uso, sem escrever código.

Como pode ficar claro na descrição acima, construir um sistema moderno de gerenciamento de regras de negócios — ou motor de decisão — é uma proposta substancial que requer profunda expertise.

Conclusão

Drools é uma boa, porém de baixo nível, abstração para um motor de regras e não um sistema moderno de gerenciamento de regras de negócios. Como tal, necessita construir inúmeras capacidades para transformá-lo em uma solução de decisão abrangente.

Oscilar é um motor de decisão moderno e em tempo real sem código. Ele automatiza a criação, enriquecimento e análise customizada de fatos ou características, combinado 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 característica a uma nova regra em minutos.