Quand ne devriez-vous PAS utiliser un moteur de règles? [fermé]

J'ai une liste assez décente des avantages d'utiliser un moteur de règles, ainsi que quelques raisons de les utiliser, ce dont j'ai besoin est une liste des raisons pour lesquelles vous ne devriez PAS utiliser un moteur de règles

Le meilleur que j'ai jusqu'à présent est celui-ci:

Les moteurs de règles ne sont pas vraiment destinés à gérer les exécutions de flux de travail ou de processus, ni les moteurs de flux de travail ou les outils de gestion de processus conçus pour créer des règles.

Y a-t-il d'autres raisons importantes pour lesquelles vous ne devriez pas les utiliser?

Je deviens très nerveux quand je vois des gens utiliser de très grands ensembles de règles (par exemple, de l'ordre de milliers de règles dans un seul ensemble de règles). Cela se produit souvent lorsque le moteur de règles est un singleton assis au centre de l'entreprise dans l'espoir que le fait de garder les règles DRY les rendra accessibles à de nombreuses applications qui en ont besoin. Je mettrais quiconque au défi de me dire qu'un moteur de règles Rete avec autant de règles est bien compris. Je ne connais aucun outil permettant de vérifier que les conflits n'existent pas.

Je pense que des ensembles de règles de partitionnement pour les garder petits est une meilleure option. Les aspects peuvent être un moyen de partager un ensemble de règles communes entre de nombreux objets.

Je préfère une approche plus simple et davantage axée sur les données dans la mesure du possible.

Je vais donner 2 exemples d'expérience personnelle où l'utilisation d'un moteur de règles était une mauvaise idée, peut-être que cela aidera: -

1. Sur un projet précédent, j'ai remarqué que les fichiers de règles (le projet utilisait Drools) contenaient beaucoup de code java, y compris des boucles, des fonctions, etc. Il s'agissait essentiellement de fichiers java se faisant passer pour un fichier de règles. Quand j'ai demandé à l'architecte son raisonnement pour la conception, on m'a dit que "les règles n'ont jamais été destinées à être maintenues par des utilisateurs professionnels".

Leçon : Elles sont appelées «règles métier» pour une raison, n'utilisez pas de règles lorsque vous ne pouvez pas concevoir un système qui puisse être facilement maintenu / compris par les utilisateurs métier.

2. Un autre cas; Le projet a utilisé des règles parce que les exigences étaient mal définies / comprises et changeaient souvent. La solution de l'équipe de développement était d'utiliser les règles de manière intensive pour éviter les déploiements fréquents de code.

Leçon : Les exigences ont tendance à beaucoup changer lors des modifications de la version initiale et ne justifient pas l'utilisation de règles. Utilisez des règles lorsque votre entreprise change souvent (pas des exigences). Par exemple: - Un logiciel qui fait vos impôts changera chaque année à mesure que les lois fiscales changent et l'utilisation des règles est une excellente idée. La version 1.0 d'une application Web changera souvent à mesure que les utilisateurs identifient de nouvelles exigences, mais se stabilisera avec le temps. N'utilisez pas de règles comme alternative au déploiement de code.

Je suis un grand fan des moteurs de règles métier, car ils peuvent vous aider à vous simplifier la vie en tant que programmeur. L'une des premières expériences que j'ai eues en travaillant sur un projet d'entrepôt de données a été de trouver des procédures stockées contenant des structures CASE complexes s'étendant sur des pages entières. Ce fut un cauchemar à déboguer, car il était très difficile de comprendre la logique appliquée dans des structures CASE aussi longues, et de déterminer si vous avez un chevauchement entre une règle à la page 1 du code et une autre de la page 5. Dans l'ensemble, nous avions plus de 300 règles de ce type intégrées dans le code.

Lorsque nous avons reçu une nouvelle exigence de développement, pour quelque chose appelé Destination comptable, qui impliquait le traitement de plus de 3000 règles, je savais que quelque chose devait changer. À l'époque, j'ai travaillé sur un prototype qui deviendra plus tard le parent de ce qui est maintenant un moteur de règles métier personnalisées, capable de gérer tous les opérateurs standard SQL. Au départ, nous avons utilisé Excel comme outil de création et, plus tard, nous avons créé une application ASP.net qui permettra aux utilisateurs professionnels de définir leurs propres règles métier, sans avoir besoin d'écrire de code. Maintenant, le système fonctionne correctement, avec très peu de bogues, et contient plus de 7000 règles pour calculer cette destination comptable. Je ne pense pas qu'un tel scénario aurait été possible par un simple codage en dur.

Pourtant, il y a des limites à une telle approche:

• Vous devez avoir des utilisateurs professionnels compétents qui ont une excellente compréhension des activités de l'entreprise.
• Il y a une charge de travail importante sur la recherche de l'ensemble du système (dans notre cas, un Data Warehouse), afin de déterminer toutes les conditions codées en dur qui ont du sens à se traduire en règles à gérer par un moteur de règles métier. Nous avons également dû veiller à ce que ces modèles initiaux soient parfaitement compréhensibles par les utilisateurs professionnels.
• Vous devez disposer d'une application utilisée pour la création de règles, dans laquelle des algorithmes de détection des règles métier qui se chevauchent sont implémentés. Sinon, vous vous retrouverez avec un gros gâchis, où personne ne comprend plus les résultats qu'ils obtiennent. Lorsque vous rencontrez un bogue dans un composant générique tel qu'un moteur de règles métier personnalisées, il peut être très difficile à déboguer et impliquer des tests approfondis pour s'assurer que les éléments qui fonctionnaient auparavant fonctionnent également maintenant.

Plus de détails sur ce sujet peuvent être trouvés sur un article que j'ai écrit: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

Dans l'ensemble, le plus grand avantage de l'utilisation d'un moteur de règles métier est qu'il permet aux utilisateurs de reprendre le contrôle des définitions et de la création des règles métier, sans avoir à se rendre au service informatique à chaque fois qu'ils doivent modifier quelque chose. Cela réduit également la charge de travail des équipes de développement informatique, qui peuvent désormais se concentrer sur la création d'éléments à plus forte valeur ajoutée.

À votre santé,

Nicolae

Le seul poit que j'ai remarqué comme étant "l'épée à double tranchant" est:

remettre la logique entre les mains du personnel non technique

J'ai vu ce travail très bien, quand vous avez un ou deux génies multidisciplinaires du côté non technique, mais j'ai aussi vu le manque de technicité conduisant à des ballonnements, plus de bugs, et en général 4x le coût de développement / maintenance.

Vous devez donc considérer sérieusement votre base d'utilisateurs.

Je pensais que l'article d'Alex Papadimoulis était assez perspicace: http://thedailywtf.com/articles/soft_coding.aspx

Ce n'est pas complet, mais il a quelques bons points.

GRAND article sur quand ne pas utiliser un moteur de règles ... (ainsi que quand en utiliser un) ....

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

Une autre option est de créer une interface groovy et de demander aux développeurs d'écrire et de déployer ces nouvelles règles si vous avez un ensemble linéaire de règles qui ne s'appliquent qu'une seule fois dans n'importe quel ordre pour obtenir un résultat. L'avantage est qu'il est incroyablement rapide car normalement vous passeriez la session de mise en veille prolongée OU la session jdbc ainsi que tous les paramètres afin que vous ayez accès à toutes les données de vos applications mais de manière efficace. Avec une liste de faits, il peut y avoir beaucoup de boucles / correspondances qui peuvent vraiment ralentir le système ..... C'est une autre façon d'éviter un moteur de règles et de pouvoir être déployé dynamiquement (oui, nos règles groovy ont été déployées dans un base de données et nous n'avons eu aucune récursivité ... soit il a rencontré la règle ou il n'a pas). C'est juste une autre option ..... oh et un autre avantage est de ne pas apprendre la syntaxe des règles pour les développeurs entrants.

Cela dépend vraiment de votre contexte. Le moteur de règles a sa place et ce qui précède n'est qu'une autre option si vous avez des règles sur un projet que vous voudrez peut-être déployer dynamiquement pour des situations très simplifiées qui ne nécessitent pas de moteur de règles.

NE PAS utiliser de moteur de règles si vous avez un jeu de règles simple et que vous pouvez avoir une interface groovy à la place ..... tout aussi déployable dynamiquement et les nouveaux développeurs qui rejoignent votre équipe peuvent l'apprendre plus rapidement que le langage bave. (Mais c'est mon avis)

D'après mon expérience, les moteurs de règles fonctionnent mieux lorsque ce qui suit est vrai:

1. Une doctrine bien définie pour votre domaine de problème
2. Données de haute qualité (de préférence automatisées) pour vous aider à gérer la plupart de vos entrées
3. Accès à des experts en la matière
4. Développeurs de logiciels ayant de l'expérience dans la création de systèmes experts

Si l'un de ces quatre traits manque, vous trouverez peut-être toujours qu'un moteur de règles fonctionne pour vous, mais chaque fois que je l'ai essayé avec même 1 manquant, j'ai rencontré des problèmes.

C'est certainement un bon début. L'autre chose avec les moteurs de règles est que certaines choses sont bien comprises, déterministes et simples. La retenue sur la paie est (ou était) comme ça. Vous pourriez l' exprimer sous forme de règles qui seraient résolues par un moteur de règles, mais vous pourriez exprimer les mêmes règles sous la forme d'une table de valeurs assez simple.

Ainsi, les moteurs de flux de travail sont bons lorsque vous exprimez un processus à plus long terme qui aura des données persistantes. Les moteurs de règles peuvent faire la même chose, mais vous devez faire beaucoup plus de complexité.

Les moteurs de règles sont bons lorsque vous avez des bases de connaissances complexes et que vous avez besoin de recherche. Les moteurs de règles peuvent résoudre des problèmes complexes et peuvent être adaptés rapidement à des situations changeantes, mais imposent beaucoup de complexité à l'implémentation de base.

De nombreux algorithmes de décision sont suffisamment simples pour être exprimés sous la forme d'un simple programme basé sur une table sans la complexité qu'implique un véritable moteur de règles.

Je recommanderais fortement les moteurs de règles métier comme Drools en open source ou les moteurs de règles commerciales tels que LiveRules.

• Lorsque de nombreuses politiques commerciales sont de nature volatile, il est très difficile de maintenir cette partie du code technologique de base.
• Le moteur de règles offre une grande flexibilité du framework et est facile à changer et à déployer.
• Les moteurs de règles ne doivent pas être utilisés partout, mais doivent être utilisés lorsque vous avez de nombreuses politiques où les changements sont inévitables sur une base régulière.

Je ne comprends pas vraiment certains points tels que:
a) les gens d'affaires doivent très bien comprendre les affaires, ou;
b) les désaccords sur les hommes d'affaires n'ont pas besoin de connaître la règle.

Pour moi, en tant que personne touchant simplement BRE, l'avantage de BRE est ainsi appelé à laisser le système s'adapter au changement de l'entreprise, par conséquent il est axé sur l'adaptation du changement.
Est-il important que la règle établie au temps x soit différente de la règle établie au temps y en raison:
a) des gens d'affaires ne comprennent pas les affaires, ou;
b) les gens d'affaires ne comprennent pas les règles?