Quando você NÃO deve usar um Mecanismo de Regras?[fechado]

Question

Eu tenho uma boa lista das vantagens de usar um Motor de Regras, bem como algumas razões para usá-los, o que eu preciso é de uma lista de razões pelas quais você NÃO deve usar um Motor de Regras de

O melhor que eu tenho até agora é esse:

Mecanismos de regras não são realmente destinado a lidar com fluxo de trabalho ou processo de execuções, nem são mecanismos de fluxo de trabalho ou ferramentas de gestão de processos projetado para fazer as regras.

Quaisquer outras grandes razões pelas quais você não deve usá-los?

Answer 1

Fico muito nervoso quando vejo pessoas usando conjuntos de regras muito grandes (por exemplo, da ordem de milhares de regras em um único conjunto de regras). Isso geralmente acontece quando o mecanismo de regras é um singleton sentado no centro da empresa, na esperança de que mantenha as regras SECO os tornará acessíveis a muitos aplicativos que os exigem. Eu desafiaria qualquer um a me dizer que um mecanismo de regras da RETE com muitas regras é bem compreendido. Não estou ciente de nenhuma ferramenta que possa verificar para garantir que os conflitos não existam.

Eu acho que os conjuntos de regras de particionamento para mantê -los pequenos são uma opção melhor. Aspectos podem ser uma maneira de compartilhar uma regra comum estabelecida entre muitos objetos.

Prefiro uma abordagem mais simples e mais orientada a dados sempre que possível.

Answer 2

Vou dar 2 exemplos da experiência pessoal, onde através de um Mecanismo de Regras foi uma má ideia, talvez isso irá ajudar:-

1. Em um projeto anterior, eu notei que as regras de ficheiros (o projeto usado Baba) continha uma grande quantidade de código java, incluindo loops, funções etc.Eles eram essencialmente arquivos java que aparece como arquivo de regras.Quando eu perguntei o arquiteto de seu raciocínio para o design foi-me dito que as "Regras nunca foram destinados a ser mantidos por usuários de negócios".

Lição:Eles são chamados de "Regras de Negócio" por um motivo, não usar as regras quando não é possível conceber um sistema que pode ser facilmente mantido/compreendido pelos usuários de Negócio.

2. Outro caso;O projeto usado regras, porque os requisitos mal definidos/compreendido e muitas vezes alterados.A equipe de desenvolvimento da solução foi o uso de regras extensivamente para evitar as frequentes código implanta.

Lição:Requisitos tendem a mudar muito durante a fase inicial de lançamento alterações e não garante o uso de regras.Regras de utilização, quando sua empresa muda, muitas vezes (não os requisitos).Por exemplo:- Um software que faz seus impostos vai mudar a cada ano, como impostos mudanças nas leis e o uso de regras é uma excelente ideia.Versão 1.0 de um aplicativo de web vai mudar, muitas vezes, como os usuários a identificar novas exigências, mas vai se estabilizar ao longo do tempo.Não usar as regras como uma alternativa para código de implantar.​

Answer 3

Sou um grande fã de motores de regras de negócios, pois isso pode 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 procedimentos armazenados contendo estruturas de casos complicadas que se estendem por páginas inteiras. Foi um pesadelo depurar, pois era muito difícil entender a lógica aplicada em estruturas de casos tão longas e determinar se você tem uma sobreposição entre uma regra na página 1 do código e outro da página 5. No geral, tivemos Mais de 300 dessas regras incorporadas no código.

Quando recebemos um novo requisito de desenvolvimento, para algo chamado destino contábil, que envolvia o tratamento de mais de 3000 regras, eu sabia que algo tinha que mudar. Naquela época, eu trabalhava em um protótipo que, mais tarde, se tornou pai do que agora é um mecanismo de regra de negócios personalizado, capaz de lidar com todos os operadores padrão do SQL. Inicialmente, usamos o Excel como uma ferramenta de autoria e, posteriormente, criamos um aplicativo ASP.NET que permitirá aos usuários de negócios definir suas próprias regras de negócios, sem a necessidade de escrever código. Agora, o sistema funciona bem, com muito poucos bugs, e contém mais de 7000 regras para calcular esse destino contábil. Eu não acho que esse cenário teria sido possível apenas com codificação. E os usuários estão muito felizes por poder definir suas próprias regras sem que se tornem seu gargalo.

Ainda assim, existem limites para essa abordagem:

• Você precisa ter usuários comerciais capazes que tenham um excelente entendimento dos negócios da empresa.
• Há uma carga de trabalho significativa na pesquisa de todo o sistema (no nosso caso, um data warehouse), a fim de determinar todas as condições codificadas que fazem sentido se traduzir em regras a serem tratadas por um mecanismo de regra de negócios. Também tivemos que cuidar bem de que esses modelos iniciais sejam totalmente compreensíveis pelos usuários de negócios.
• Você precisa ter um aplicativo usado para a criação de regras, na qual os algoritmos para detecção de regras de negócios sobrepostas são implementadas. Caso contrário, você acabará com uma grande bagunça, onde ninguém entende mais os resultados que eles obtêm. Quando você tem um bug em um componente genérico como um mecanismo de regras de negócios personalizado, pode ser muito difícil depurar e envolver testes extensos para garantir que as coisas que funcionassem antes de também trabalhar agora.

Mais detalhes sobre este tópico podem ser encontrados em um post que eu escrevi: http://dwhbp.com/post/2011/10/30/implementing-business-rule-engine.aspx

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

Saúde,

Nicolae

Answer 4

O único Poit que notei ser "The Double Gidged Sword" é:

colocando a lógica nas mãos da equipe não técnica

Eu já vi esse trabalho muito bem, quando você tem um ou dois gênios multidisciplinares no lado não técnico, mas também vi a falta de tecnicidade levando a inchaço, mais bugs e, em geral, 4x o custo de desenvolvimento/manutenção.

Assim, você precisa considerar sua base de usuário seriamente.

Answer 5

Eu pensei que o artigo de Alex Papadimoulis era bastante perspicaz: http://thedailywtf.com/articles/soft_coding.aspx

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

Answer 6

Ótimo artigo sobre quando não usar um mecanismo de regras ... (assim 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 Groovy e fazer com que os desenvolvedores escrevam e implantem essas novas regras. A vantagem é que é perversamente rápido, porque normalmente você passaria na sessão de hibernato ou na sessão JDBC, bem como em qualquer parâmetros para ter acesso a todos os dados de seus aplicativos, mas de maneira eficiente. Com uma lista de fatos, pode haver um monte de loop/correspondência que realmente pode diminuir o sistema ... é outra maneira de evitar um mecanismo de regras e poder ser implantado dinamicamente (sim, nossas regras groovy foram implantadas em um Banco de dados e não tivemos recursão .... nem atendeu à regra ou não). É apenas mais uma opção ..... oh, e mais um benefício não é a sintaxe das regras de aprendizado para os desenvolvedores de entrada. Eles precisam aprender um pouco de groovy, mas isso é muito próximo de Java, para que a curva de aprendizado seja muito melhor.

Realmente depende do seu contexto. O mecanismo de regras tem seu lugar e o acima é apenas mais uma opção se você tiver regras em um projeto que você queira 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 pode ter uma interface groovy ..... igualmente dinamicamente implantável e novos desenvolvedores que se juntam à sua equipe podem aprender mais rapidamente que a linguagem Drools. (Mas essa é a minha opinião)

Answer 7

Na minha experiência, os motores de regras funcionam melhor quando os seguintes são verdadeiros:

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

Se alguma dessas quatro características estiver faltando, você ainda poderá encontrar um mecanismo de regras funcionar para você, mas toda vez que eu o experimentei com até 1 falta, tenho problemas.

Answer 8

That's certainly a good start. The other thing with rules engines is that some things are well-understood, deterministic, and straight-forward. Payroll withholding is (or use to be) like that. You could express it as rules that would be resolved by a rules engine, but you could express the same rules as a fairly simple table of values.

So, workflow engines are good when you're expressing a longer-term process that will have persistent data. Rules engines can do a similar thing, but you have to do a lot of added complexity.

Rules engines are good when you have complicated knowledge bases and need search. Rules engines can resolve complicated issues, and can be adapted quickly to changing situations, but impose a lot of complexity on the base implementation.

Many decision algorithms are simple enough to express as a simple table-driven program without the complexity implied by a real rules engine.

Answer 9

I would strongly recommend business rules engines like Drools as open source or Commercial Rules Engine such as LiveRules.

• When you have a lot of business policies which are volatile in nature, it is very hard to maintain that part of the core technology code.
• The rules engine provides a great flexibility of the framework and easy to change and deploy.
• Rules engines are not to be used everywhere but need to used when you have lot of policies where changes are inevitable on a regular basis.

Answer 10

I don't really understand some points such as :
a) business people needs to understand business very well, or;
b) disagreement on business people don't need to know the rule.

For me, as a people just touching BRE， the benefit of BRE is so called to let system adapt to business change, hence it's focused on adaptive of change.
Does it matter if the rule set up at time x is different from the rule set up at time y because of:
a) business people don't understand business, or;
b) business people don't understand rules?