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

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?

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.

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.

2. 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.

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

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.

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

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

Ó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)

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.

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.

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.

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?