Quand devriez-vous PAS utiliser un moteur de règles?

Question

J'ai une bonne liste des avantages d'utiliser un moteur de règles, ainsi que des raisons de les utiliser. Ce dont j'ai besoin, c'est d'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 la suivante:

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

D'autres grandes raisons pour lesquelles vous ne devriez pas les utiliser?

Answer 1

Je vais donner 2 exemples à partir de l'expérience personnelle où l'utilisation d'un Moteur de Règles était une mauvaise idée, peut-être vous aider:-

1. Sur un projet, j'ai remarqué que les fichiers de règles (le projet a utilisé Bave) contenait beaucoup de code java, y compris les boucles, fonctions, etc. Ils étaient essentiellement des fichiers java en se faisant passer pour des fichier de règles. Quand j'ai demandé à l'architecte de son raisonnement pour la conception m'a dit que "les Règles n'ont jamais été destinées à être maintenu par les utilisateurs de l'entreprise".

Leçon: Ils sont appelés "Règles Métier" pour une raison, ne pas utiliser de règles lorsque vous ne pouvez pas concevoir un système qui peut être facilement mis à jour/compris par les utilisateurs de l'Entreprise.

1. Un autre cas, Le projet a utilisé des règles parce que les exigences ont été mal définis/compris et changé souvent. L'équipe de développement de la solution a été d'utiliser les règles de façon intensive pour éviter de fréquentes code déploie.

Leçon: les Exigences ont tendance à changer beaucoup de choses au cours de publication initiale modifications et ne justifient pas l'utilisation de règles. Règles d'utilisation lorsque votre entreprise change souvent (pas une obligation). Par exemple:- d'Un logiciel qui ne vos impôts vont changer chaque année d'imposition de modification de la législation et de l'utilisation des règles est une excellente idée. La version 1.0 de l'application web va changer souvent que les utilisateurs à identifier de nouvelles exigences, mais qui va se stabiliser au fil du temps. N'utilisez pas de règles comme une alternative au code de déployer.

Answer 2

Je suis très nerveux quand je vois des gens à l'aide de très grands ensembles de règles (par exemple, sur l'ordre de plusieurs 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 dans le centre de l'entreprise dans l'espoir que l'observance de règles à SEC permettra de les rendre accessible à de nombreuses applications qui en ont besoin. Je défie quiconque de me dire qu'une Araignée de moteur de règles avec beaucoup de règles est bien comprise. Je ne suis pas au courant de tous les outils qui peuvent vérifier pour s'assurer que les conflits n'existent pas.

Je pense que le partitionnement des jeux de règles de garder leur petit est une meilleure option. Peut-être une façon de partager un ensemble de règle parmi de nombreux objets.

Je préfère une méthode plus simple, plus dynamiques approche dans la mesure du possible.

Answer 3

Je suis un grand fan de Règles de gestion des Moteurs, car il peut vous aider à rendre votre vie beaucoup plus facile en tant que programmeur. L'une des premières expériences que j'ai eu en travaillant sur un projet d'Entrepôt de Données a été de trouver des Procédures Stockées contenant de CAS complexe des structures qui s'étend sur des pages entières. Il a été un cauchemar pour le débogage, car il était très difficile de comprendre la logique appliquée dans de tels CAS des structures, et de déterminer si vous avez un chevauchement entre une règle à la page 1 du code et de l'autre à partir de la page 5. Dans l'ensemble, nous avons eu plus de 300 de ces règles intégrées dans le code.

Lorsque nous avons reçu les nouvelles exigences de développement, de quelque chose qui s'appelle la Comptabilité de Destination, qui était impliquant le traitement de plus de 3000 règles, je savais que quelque chose devait changer. A l'époque, j'ai travaillé sur un prototype qui plus tard pour devenir le parent de ce qui est maintenant une Coutume moteur de règles d'Entreprise, capable de traiter tous de la norme SQL opérateurs. Au départ, nous avons été à l'aide d'Excel comme un outil de création et , plus tard, nous avons créé une ASP.net application qui permettra aux Utilisateurs de définir leurs propres règles métier, sans avoir besoin d'écrire de code. Maintenant, le système fonctionne très bien, avec très peu de bugs, et contient plus de 7000 règles pour le calcul de cette Comptabilité de Destination. Je ne pense pas qu'un tel scénario aurait été juste de coder en dur. Et les utilisateurs sont assez heureux qu'ils peuvent définir leurs propres règles sans que CELA devienne leur goulot d'étranglement.

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

• Vous avez besoin d'avoir capable d'entreprise les utilisateurs qui ont une excellente compréhension de l'activité de la société.
• Il y a une charge de travail importante à la recherche de l'ensemble du système (en notre cas d'un Entrepôt de Données), afin de déterminer tous codés en dur des conditions qui font sens pour traduire dans les règles pour être manipulé par un Moteur de règles. Nous avons aussi eu à prendre soin de ces initiale des modèles pour être parfaitement compréhensibles par les Utilisateurs.
• Vous avez besoin d'une application utilisée pour les règles de création, dans lequel algorithmes pour la détection de chevauchement des règles de gestion mises en œuvre. Sinon vous vous retrouverez avec un gros gâchis, où personne ne comprend plus les résultats qu'ils obtiennent. Lorsque vous avez un bug dans un composant générique comme une Coutume Moteur de règles, il peut être très difficile à déboguer et d'impliquer des tests approfondis pour s'assurer que les choses qui a travaillé également à travailler maintenant.

Plus de détails à ce sujet peuvent être trouvées sur un post 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'une Règle d'Entreprise Moteurs est qu'il permet aux utilisateurs de reprendre le contrôle sur les Affaires de définitions de règles et de création, sans avoir besoin d'aller pour le département chaque fois qu'ils ont besoin de modifier quelque chose. C'est aussi le réduit la charge de travail de plus de équipes de développement informatique, qui peut maintenant se concentrer sur le renforcement des trucs avec plus de valeur ajoutée.

Cheers,

Nicolae

Answer 4

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

placer la logique entre des mains de personnel non technique

J'ai bien vu ce travail, 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.

Par conséquent, vous devez prendre au sérieux votre clientèle.

Answer 5

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 de bons points.