Aplicativos "baseados em regras" altamente escaláveis ​​e dinâmicos?

Para um aplicativo corporativo de grande porte, todos sabem que ser capaz de se adaptar às mudanças é um dos aspectos mais importantes do design. Eu uso uma abordagem baseada em regras a maior parte do tempo para lidar com a alteração da lógica de negócios, com cada regra sendo armazenada em um banco de dados. Isso permite que alterações fáceis sejam feitas sem entrar em detalhes desagradáveis. Agora, como o C # não pode Eval ("foo (bar);"), isso é feito usando cadeias formatadas armazenadas em linhas que são processadas em JavaScript no tempo de execução. Isso funciona bem, no entanto, é menos do que elegante e não seria o mais agradável para alguém entender depois que se tornar legado.

Existe uma solução mais elegante para isso? Quando você adota milhares de regras que mudam com bastante frequência, isso se torna um problema real, mas isso não pode ser tão incomum em um problema que alguém não pensou em uma maneira melhor de fazer isso. Alguma sugestão? Esse método atual é defensável? Quais são as alternativas?

Edit: Apenas para esclarecer, este é um aplicativo corporativo de grande porte, portanto, não importa qual solução funcione, haverá muitas pessoas constantemente mantendo suas regras e dados (cerca de 10). Além disso, os dados são alterados com frequência suficiente para dizer que algum tipo de sistema de servidor centralizado é basicamente necessário.

Eu usaria o WF ou o Drools se você estiver tentando criar uma abstração com a qual os não programadores possam trabalhar para desenvolver regras de negócios. No entanto, se você está lidando com programadores, a abstração do WF não vale o tempo necessário para desenvolver uma solução, não vejo o valor agregado do seu investimento.

Um banco de dados é uma boa maneira de manter regras que podem mudar muito, mas deixe-me sugerir uma alternativa possível (não necessariamente melhor, mas uma alternativa).

1) Separe a lógica de negócios em sua própria camada (dll) - abstraindo como você a está chamando com algumas interfaces (veja os padrões de estratégia e observador), por exemplo, IRuleEvaluator.Evaluate (string myParams).

2) Agora você pode criar classes discretas para cada regra (se necessário) e testes de unidade acompanhantes.

3) Agora, para a Pièce de résistance, conecte tudo nos bastidores em um contêiner do COI - a dll e a instância do avaliador de regras. Dessa forma, seu avaliador de regras é construído através da configuração no tempo de execução - nada é codificado juntos.

Essa abordagem é muito dinâmica (talvez dinâmica demais para alguns gostos) - permitirá que você faça testes unitários discretos reais para todas as suas regras. Se você precisar reimplantar ou alterar uma regra, poderá soltar uma nova DLL, alterar seu arquivo de configuração do IOC, reiniciar e verificar - ou reverter a alteração se algo estiver errado - sem modificar seu código principal (como um base de dados). E, diferentemente de um banco de dados, ele manterá a lógica e o código do aplicativo sob um guarda-chuva, em vez de metade escrita em C # e metade em SQL.

Existem dois casos de regras que eu já vi. Na maioria dos casos, a regra em si não é muito volátil (quase fixa), mas os dados nos quais a decisão é tomada podem ser alterados pelos usuários comerciais. Nesse caso, padrões de design simples para encapsular cada regra com a leitura dos dados de referência do DataBase geralmente são suficientes. Em seguida, forneça um front-end para alterar os dados de referência das regras.

Os outros casos em que a própria lógica da regra pode ser alterada dinamicamente. Uma abordagem seria usar o IronPython ou outras linguagens dinâmicas (na .Net 4) para implementar as regras e carregá-las dinamicamente no tempo de execução. Isso é um compromisso, pois você ainda precisará que os programadores alterem as regras.

Se você realmente deseja que as regras sejam editáveis ​​pelos usuários comerciais, a criação de DSL para o seu domínio comercial é uma abordagem a ser adotada. Este é um empreendimento complexo.

Finalmente, o uso do Workflow ou do BizTalk pode ajudar se as regras se ajustarem aos padrões de transformação / orquestração.

Se você estiver projetando um aplicativo "baseado em regras" altamente escalável, no qual as regras estão sujeitas a mudanças frequentes nos negócios, considere os produtos BRMS líderes de mercado, como: 1. IBM WODM 2. FICO BLAZE Advisor 3. Babos (código aberto)

Tenho trabalhado em grandes aplicações comerciais com uma abordagem BRMS, que as tornam altamente escaláveis ​​e fáceis de manter, além de torná-las muito flexíveis com o tempo de inatividade ZERO na produção. Faz negócios felizes. :)

Estou assumindo que você não estava se referindo estritamente às operações do lado do cliente e está no .Net desde que mencionou c # ...

Se você estiver na estrutura 4, possui o DLR (dynamic language runtime) ou em qualquer estrutura, se estiver armazenando as regras no sql, também poderá processá-las lá ou sempre usar o linq dinâmico nas estruturas> 3 ou escrever as diferentes funções como montagens que podem ser carregadas por nome em tempo de execução através de uma carga de montagem.

Nem todos são elegantes em muitos casos, mas tive que usá-los todas as vezes.

Uma coisa que vem à mente é o Windows Workflow Foundation , que pode ser usado junto com o ASP.NET, mas seria executado no lado do servidor (portanto, pode não ser aplicável ao que você está fazendo). Em Java, existe o jBPM (gerenciamento de processos de negócios), que também é executado no lado do servidor.

Como essas soluções provavelmente não atendem às suas expectativas , a melhor coisa a fazer é implementar essas regras de negócios em código antigo simples (usando javascript, C # ou o que for melhor para o trabalho) e esperar que o código de programação seja precisa ser atualizado quando ocorrerem alterações no design. O uso de padrões de design orientados a objetos tornará o código facilmente extensível. Se você escrever bem o código, o esforço necessário para alterá-lo no futuro deve ser mínimo.

Se suas regras tiverem todos um formato

if <condition>
then <action>
[else <action]

Você pode usar o Drools.NET ou outra implementação do Rete, como o iLog.