Quando você NÃO deve usar um mecanismo de regras? [fechadas]


108

Eu tenho uma lista bastante decente das vantagens de usar um Mecanismo de Regras, bem como alguns motivos para usá-los, o que eu preciso é uma lista dos motivos pelos quais você NÃO deve usar um Mecanismo de Regras

O melhor que tenho até agora é este:

Os mecanismos de regras não se destinam realmente a lidar com o fluxo de trabalho ou execuções de processos, nem são os mecanismos de fluxo de trabalho ou ferramentas de gerenciamento de processos projetados para executar regras.

Alguma outra razão importante para você não usá-los?


Respostas:


34

Fico muito nervoso quando vejo pessoas usando conjuntos de regras muito grandes (por exemplo, na ordem de milhares de regras em um único conjunto de regras). Isso geralmente acontece quando o mecanismo de regras é um único sentando no centro da empresa na esperança de que manter as regras DRY as tornará acessíveis a muitos aplicativos que as exigem. Eu desafiaria qualquer um a me dizer que um mecanismo de regras Rete com tantas regras é bem compreendido. Não conheço nenhuma ferramenta que possa verificar se não há conflitos.

Acho que o particionamento de conjuntos de regras para mantê-los pequenos é a melhor opção. Os aspectos podem ser uma forma de compartilhar uma regra comum definida entre muitos objetos.

Prefiro uma abordagem mais simples e baseada em dados sempre que possível.


1
Determinar se há algum conflito não seria uma variante do problema de Halting?
TMB

Não sei se é assim que você chama. O que muda usando esse nome? Nada que eu possa ver ...
duffymo

@duffymo algum exemplo para a "abordagem mais baseada em dados"?
jack.the.ripper

Claro: coloque suas coisas em uma única tabela de decisão e consulte para obter as respostas que deseja. Não há necessidade de mecanismo de regras Rete.
duffymo

151

Vou dar 2 exemplos de experiência pessoal em que usar um mecanismo de regras foi uma má ideia, talvez isso ajude: -

  1. Em um projeto anterior, percebi que os arquivos de regras (o projeto usava Drools) continham muitos códigos java, incluindo loops, funções etc. Eles eram essencialmente arquivos java mascarados como arquivos de regras. Quando perguntei ao arquiteto sobre o raciocínio dele para o projeto, fui informado que "as regras nunca foram feitas para serem mantidas por usuários comerciais".

Lição : Elas são chamadas de "Regras de Negócios" por uma razão, não use regras quando você não puder projetar um sistema que possa ser facilmente mantido / compreendido por usuários de Negócios.

  1. Outro caso; O projeto usava regras porque os requisitos eram mal definidos / compreendidos e mudados com frequência. A solução da equipe de desenvolvimento foi usar regras extensivamente para evitar implantações de código frequentes.

Lição : os requisitos tendem a mudar muito durante as mudanças iniciais da versão e não garantem o uso de regras. Use regras quando seu negócio muda frequentemente (não requisitos). Por exemplo: - Um software que faz seus impostos muda a cada ano conforme as leis tributárias mudam e o uso de regras é uma excelente ideia. A versão 1.0 de um aplicativo da web mudará frequentemente à medida que os usuários identificam novos requisitos, mas se estabilizará com o tempo. Não use regras como alternativa à implantação de código.


1
Acho que uma boa maneira de reformular sua lição nº 2 é "não implemente DSL quando você sabe que a abstração contida pela DSL provavelmente mudará". Projetar e implementar DSL é um processo de muitos recursos que você pretende colher prêmios no futuro. Se você tiver que recriar DSL cada ciclo, em seguida, o mecanismo de regras não vai ser um bom ajuste ainda até que alguma estabilização acontece.
ESTE USUÁRIO PRECISA DE AJUDA DE 1º de

Uma DSL pode ter muitos recursos da mesma forma que as linguagens de programação interpretadas são pesadas, mas também podem ser digitados estáticos e compilados na mudança, assim como outras linguagens compiladas.
Matthew Whited

19

Sou um grande fã dos Business Rules Engines, pois podem ajudá-lo a tornar sua vida muito mais fácil como programador. Uma das primeiras experiências que tive enquanto trabalhava em um projeto de Data Warehouse foi encontrar Stored Procedures contendo estruturas CASE complicadas estendendo-se por páginas inteiras. Depurar foi um pesadelo, já que era muito difícil entender a lógica aplicada em estruturas CASE tão longas e determinar se havia uma sobreposição entre uma regra na página 1 do código e outra na página 5. No geral, tivemos mais de 300 dessas regras embutidas no código.

Quando recebemos um novo requisito de desenvolvimento, para algo chamado Destino Contábil, que envolvia o tratamento de mais de 3.000 regras, eu sabia que algo tinha que mudar. Naquela época, eu estava trabalhando em um protótipo que mais tarde se tornou o pai do que agora é um mecanismo de Regras de negócios personalizadas, capaz de lidar com todos os operadores padrão SQL. Inicialmente utilizamos o Excel como ferramenta de autoria e, posteriormente, criamos um aplicativo ASP.net que permitirá aos Usuários de Negócios definirem suas próprias regras de negócio, sem a necessidade de escrever código. Agora o sistema funciona bem, com pouquíssimos bugs, e contém mais de 7000 regras para o cálculo deste Destino Contábil. Não acho que tal cenário seria possível apenas com a codificação permanente.

Ainda assim, há limites para essa abordagem:

  • Você precisa ter usuários de negócios capazes, que tenham um excelente conhecimento dos negócios da empresa.
  • Há uma carga de trabalho significativa na busca de todo o sistema (no nosso caso, um Data Warehouse), a fim de determinar todas as condições embutidas em código que fazem sentido traduzir em regras a serem tratadas por um Business Rule Engine. Também tivemos que tomar cuidado para que esses modelos iniciais fossem totalmente compreensíveis pelos usuários de negócios.
  • Você precisa ter um aplicativo usado para criação de regras, no qual algoritmos para detecção de regras de negócios sobrepostas sejam implementados. Caso contrário, você acabará em uma grande confusão, onde ninguém mais entende os resultados que obtém. Quando você tem um bug em um componente genérico, como um Custom Business Rule Engine, pode ser muito difícil depurar e envolver testes extensivos para garantir que as coisas que funcionavam antes também funcionem agora.

Mais detalhes sobre este tópico podem ser encontrados em uma postagem que escrevi: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

No geral, a maior vantagem de usar um Mecanismo de regra de negócios é que ele permite que os usuários retomem o controle sobre as definições e a criação de regras de negócios, sem a necessidade de ir ao departamento de TI toda vez que precisarem modificar algo. Isso também reduz a carga de trabalho das equipes de desenvolvimento de TI, que agora podem se concentrar na construção de coisas com mais valor agregado.

Felicidades,

Nicolae


18

A única coisa que percebi ser "a espada de dois gumes" é:

colocar a lógica nas mãos de pessoal não técnico

Já vi esse trabalho ótimo, quando você tem um ou dois gênios multidisciplinares do lado não técnico, mas também vi a falta de tecnologia levando ao inchaço, mais bugs e em geral 4x o custo de desenvolvimento / manutenção.

Portanto, você precisa considerar seriamente sua base de usuários.


13
A culpa é sua como programador e não do usuário se ele não puder usar o seu sistema ou se ele obtiver resultados imprevisíveis com ele, seja um BRE ou não. Eu diria que culpar os usuários por sua incapacidade de usar seu código é o tipo absolutamente pior de programação que um projeto pode ter.
Kizz

Embora seja um post muito antigo, mas eu simplesmente não posso concordar mais. Acho que, se possível, pessoal técnico (ou fornecedor) para fazer a configuração para os clientes durante o processo de implementação / integração e, em seguida, qualquer alteração importante na base de solicitação de serviço.
Eric Xin Zhang

Talvez alguém ache útil ler um bom artigo escrito por Martin Fowler sobre DSL-s: "As DSLs permitirão que os empresários escrevam regras de software sem envolver programadores?" martinfowler.com/bliki/BusinessReadableDSL.html
Robert Lujo

11

Achei o artigo de Alex Papadimoulis bastante esclarecedor: http://thedailywtf.com/articles/soft_coding.aspx

Não é abrangente, mas ele tem alguns pontos positivos.


2
problema é que não fala sobre motores de regras padrão reais, apenas sobre feitos em casa, o que é uma ideia muito ruim, estou falando sobre motores de regras padrão (Blaze Advisor, ILog, Drools) que implementam o algoritmo RETE e fornecem um todo ecossistema para gerenciar regras
BlackTigerX

artigo incrível e eu acho que você pode ir muito suave com um mecanismo de regras padrão, às vezes tornando as coisas mais complexas
Dean Hiller

1
Imagine um banco com milhões de transações por hora perdida de conexão com mecanismo de regra de cálculo de taxas por 30 minutos porque os desenvolvedores têm depolização, imagine que este foi um período de estabilidade onde eles têm muitas implantações para correções, quanta perda eles terão apenas por colocar em parada um serviço de negociação de ações, câmbio ou transferências SWIFT? Este é um dos piores artigos sobre programação em geral

2
hragheb, de onde vêm os 30 minutos de inatividade? Gigantes como o Facebook implantam constantemente novos softwares sem tempo de inatividade. Os aplicativos podem ser construídos para suportar a atualização de nós em lotes em vez de desativar todo o sistema.
Lauri Harpf

10

ÓTIMO artigo sobre quando não usar um mecanismo de regras ... (bem como quando usar um) ....

http://www.jessrules.com/guidelines.shtml

Outra opção é se você tiver um conjunto linear de regras que se aplicam apenas uma vez em qualquer ordem para obter um resultado, é criar uma interface bacana e fazer com que os desenvolvedores escrevam e implantem essas novas regras. A vantagem é que é incrivelmente rápido porque normalmente você passaria a sessão de hibernação OU a sessão jdbc, bem como quaisquer parâmetros, para ter acesso a todos os dados de seus aplicativos, mas de maneira eficiente. Com uma lista de fatos, pode haver muitos loops / correspondências que realmente podem tornar o sistema lento ... É outra maneira de evitar um mecanismo de regras e ser capaz de ser implantado dinamicamente (sim, nossas regras legais foram implantadas em um banco de dados e não tivemos recursão ... ou atendeu à regra ou não). É apenas outra opção ... ah, e mais um benefício é não aprender a sintaxe das regras para os desenvolvedores que estão entrando.

Realmente depende do seu contexto. O mecanismo de regras tem seu lugar e o acima é apenas outra opção se você tiver regras em um projeto que deseja implantar dinamicamente para situações muito simplificadas que não exigem um mecanismo de regras.

BASICAMENTE, NÃO use um mecanismo de regras se você tiver um conjunto de regras simples e, em vez disso, puder ter uma interface bacana ... tão dinamicamente implantável e novos desenvolvedores que se juntam à sua equipe podem aprender mais rápido do que a linguagem drools. (Mas essa é minha opinião)


7

Na minha experiência, os mecanismos de regras funcionam melhor quando o seguinte é verdadeiro:

  1. Doutrina bem definida para o domínio do seu problema
  2. Dados de alta qualidade (de preferência automatizados) para ajudar a impulsionar a maioria de suas entradas
  3. Acesso a especialistas no assunto
  4. Desenvolvedores de software com experiência na criação de sistemas especialistas

Se qualquer uma dessas quatro características estiver faltando, você ainda pode achar que um mecanismo de regras funciona para você, mas sempre que tentei com apenas 1 faltando, tive problemas.


this> _Desenvolvedores de software com experiência na criação de sistemas especialistas_ <Se você ler a documentação do drools cuidadosamente, perceberá que as regras de negócios devem ser implementadas por desenvolvedores de software que têm um forte conhecimento do Algoritmo de Rete. O acesso à parametrização das regras pode ser disponibilizado aos usuários empresariais por meio de planilhas ou CSV. No entanto, as regras são descritas por usuários de negócios, mas implementadas, como você diz, por desenvolvedores de software com experiência em sistemas especialistas. Os documentos do drools descrevem isso.
Matt Friedman

1

Certamente é um bom começo. A outra coisa com os mecanismos de regras é que algumas coisas são bem compreendidas, determinísticas e diretas. Retenção de folha de pagamento é (ou costumava ser) assim. Você poderia expressá-lo como regras que seriam resolvidas por um mecanismo de regras, mas poderia expressar as mesmas regras como uma tabela de valores bastante simples.

Portanto, os mecanismos de fluxo de trabalho são bons quando você está expressando um processo de longo prazo que terá dados persistentes. Os mecanismos de regras podem fazer algo semelhante, mas você precisa fazer uma grande complexidade adicional.

Os mecanismos de regras são bons quando você tem bases de conhecimento complicadas e precisa de pesquisa. Os mecanismos de regras podem resolver problemas complicados e podem ser adaptados rapidamente a situações de mudança, mas impõem muita complexidade na implementação básica.

Muitos algoritmos de decisão são simples o suficiente para serem expressos como um programa simples baseado em tabelas, sem a complexidade implícita em um mecanismo de regras real.


0

Eu recomendaria fortemente mecanismos de regras de negócios como Drools como código aberto ou Mecanismos de Regras Comerciais como LiveRules.

  • Quando você tem muitas políticas de negócios de natureza volátil, é muito difícil manter essa parte do código de tecnologia central.
  • O mecanismo de regras fornece uma grande flexibilidade da estrutura e é fácil de alterar e implementar.
  • Os mecanismos de regras não devem ser usados ​​em todos os lugares, mas precisam ser usados ​​quando você tem muitas políticas nas quais as alterações são inevitáveis ​​regularmente.

0

Eu realmente não entendo alguns pontos como:
a) os empresários precisam entender muito bem os negócios, ou;
b) desacordo sobre empresários não precisam conhecer a regra.

Para mim, como uma pessoa que está tocando o BRE, o benefício do BRE é assim chamado para permitir que o sistema se adapte às mudanças nos negócios, portanto, é focado na adaptação à mudança.
Faz diferença se a regra configurada no momento x é diferente da regra configurada no momento y devido a:
a) empresários não entenderem de negócios ou;
b) os empresários não entendem as regras?

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.