Quand devriez-vous PAS utiliser un moteur de règles?
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, ni 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?
Je suis très nerveux lorsque je vois des personnes 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 situé au centre de l'entreprise, dans l'espoir que le respect des règles DRY les rendra accessibles à de nombreuses applications nécessitant leur. Je défierais quiconque 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 les règles de partitionnement pour les garder petites sont une meilleure option. Les aspects peuvent être un moyen de partager un ensemble de règles communes entre plusieurs objets.
Je préfère une approche plus simple, davantage axée sur les données, dans la mesure du possible.
Je vais donner 2 exemples d’expérience personnelle où utiliser un moteur de règles était une mauvaise idée, cela aidera peut-être: -
- Lors d’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. Ils étaient essentiellement des fichiers Java se faisant passer pour des règles. fichier. Quand j'ai demandé à l'architecte son raisonnement pour la conception, on m'a répondu que les "règles ne devaient jamais être maintenues par les utilisateurs professionnels".
Leçon: Elles sont appelées "règles de gestion" pour une raison. N'utilisez pas de règles lorsque vous ne pouvez pas concevoir un système pouvant être facilement géré/compris par les utilisateurs de l'entreprise.
- Un autre cas; Le projet a utilisé des règles car les exigences étaient mal définies/comprises et changées souvent. La solution de l'équipe de développement consistait à utiliser de manière intensive les règles pour éviter les déploiements fréquents de code.
Leçon: Les exigences ont tendance à beaucoup changer pendant les changements de version initiale et ne justifient pas l'utilisation de règles. Utilisez des règles lorsque votre entreprise change souvent (pas d'exigences). Par exemple: - Un logiciel qui modifie vos impôts changera chaque année en fonction de l'évolution des lois fiscales et l'utilisation des règles est une excellente idée. La version 1.0 d'une application Web change souvent lorsque les utilisateurs identifient de nouvelles exigences, mais elle se stabilise avec le temps. N'utilisez pas de règles comme alternative au déploiement de code. Un séjour sans faille
Je suis un grand fan des moteurs de règles métier, car cela peut vous aider à vous simplifier la vie beaucoup en tant que programmeur. L'une des premières expériences que j'ai eues dans le cadre d'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. C'était un cauchemar à déboguer, car il était très difficile de comprendre la logique appliquée dans de si longues structures CASE et de déterminer s'il y avait un chevauchement entre une règle à la page 1 du code et une autre à la page 5. Dans l'ensemble, nous avions plus de 300 règles de ce type sont 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 3 000 règles, je savais que quelque chose devait changer. À l'époque, je travaillais sur un prototype qui deviendra plus tard le parent de ce qui est maintenant un moteur de règles métier personnalisé, capable de gérer tous les opérateurs standard SQL. Au départ, nous utilisions 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 commerciales sans avoir à écrire de code. Maintenant, le système fonctionne correctement, avec très peu de bugs et contient plus de 7 000 règles pour calculer cette destination de comptabilisation. Je ne pense pas qu'un tel scénario aurait été possible simplement en codant en dur. Et les utilisateurs sont assez heureux de pouvoir définir leurs propres règles sans que l'informatique ne devienne leur goulet d'étranglement.
Néanmoins, il existe des limites à une telle approche:
- Vous devez avoir des utilisateurs professionnels compétents qui possèdent une excellente compréhension des activités de la société.
- La recherche dans l'ensemble du système (dans notre cas, un entrepôt de données) représente une charge de travail importante, afin de déterminer toutes les conditions codées en dur qui ont un sens à traduire en règles à gérer par un moteur de règles métier. Nous devons également 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 mis en œuvre. Sinon, vous vous retrouverez avec un gros gâchis, où personne ne comprend plus les résultats obtenus. Lorsque vous rencontrez un bogue dans un composant générique tel qu'un moteur de règles métier personnalisé, il peut s'avérer très difficile à déboguer et à impliquer des tests approfondis pour vous assurer que les éléments qui fonctionnaient auparavant fonctionnent également.
Plus de détails sur ce sujet peuvent être trouvés sur un post que j'ai écrit: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx
Globalement, le principal avantage de l'utilisation de moteurs de règles métier est qu'il permet aux utilisateurs de reprendre le contrôle des définitions et de la création de règles métier, sans qu'il soit nécessaire de s'adresser 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 offrant davantage de valeur ajoutée.
À votre santé,
Nicolae
Le seul que j'ai remarqué comme étant "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.
Ainsi, vous devez considérer votre base d'utilisateurs sérieusement.
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.
Grand article sur quand ne pas utiliser un moteur de règles ... (ainsi que quand l'utiliser) ....
http://www.jessrules.com/guidelines.shtml
Une autre option est que 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, vous devez créer une interface groovy et permettre aux développeurs d'écrire et de déployer ces nouvelles règles. L’avantage est qu’elle est extrêmement rapide, car normalement, vous passez la session d’hibernation OR La session jdbc ainsi que tous les paramètres vous permettant d’avoir accès à toutes les données de vos applications, mais de manière efficace. En fait, il peut y avoir beaucoup de boucles et de correspondances qui peuvent vraiment ralentir le système. C’est un autre moyen d’éviter un moteur de règles et de pouvoir être déployé de manière dynamique (oui, nos règles groovy ont été déployées dans une base de données). nous n’avions pas de récursivité… soit il respectait la règle, soit ce n’était pas le cas. C’est juste une autre option… oh et l’avantage supplémentaire n’est pas d’apprendre la syntaxe des règles pour les développeurs entrants. mais c'est très proche de Java alors la courbe d'apprentissage est bien meilleure.
Cela dépend vraiment de votre contexte. Le moteur de règles a sa place et l'option ci-dessus n'est qu'une autre option si vous avez des règles sur un projet que vous pouvez déployer de manière dynamique pour des situations très simplifiées ne nécessitant pas de moteur de règles.
En principe, n'utilisez PAS de moteur de règles si vous avez un jeu de règles simple et pouvez avoir une interface groovy à la place ... tout aussi dynamiquement déployable et les nouveaux développeurs rejoignant votre équipe peuvent l'apprendre plus rapidement que le langage bavard (mais c'est mon opinion).
D'après mon expérience, les moteurs de règles fonctionnent mieux lorsque les conditions suivantes sont vraies:
- Bien défini doctrine pour votre domaine problématique
- Données de haute qualité (de préférence automatisées) pour vous aider à gérer la plupart de vos entrées
- Accès à des experts en la matière
- Développeurs de logiciels expérimentés dans la création de systèmes experts
Si l'un de ces quatre traits est manquant, vous pouvez toujours trouver un moteur de règles qui vous convient, mais chaque fois que je l'ai essayé avec un seul manquant, j'ai eu 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 directes. 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 forme de tableau de valeurs assez simple.
Les moteurs de workflow sont donc utiles lorsque vous exprimez un processus à long terme comportant des données persistantes. Les moteurs de règles peuvent faire la même chose, mais il faut ajouter beaucoup de complexité.
Les moteurs de règles sont utiles lorsque vous avez des bases de connaissances complexes et que vous devez effectuer une 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é à la mise en œuvre de base.
De nombreux algorithmes de décision sont suffisamment simples pour être exprimés sous la forme d'un simple programme piloté par une table, sans la complexité qu'implique un véritable moteur de règles.
Je ne comprends pas vraiment certains points tels que:
a) les gens d’affaires ont besoin de bien comprendre les affaires, ou;
b) le désaccord sur les hommes d'affaires n'a pas besoin de connaître la règle.
Pour moi, en tant que peuple qui touche à BRE, l'avantage de BRE est appelé à permettre au système de s'adapter au changement de l'entreprise, il est donc axé sur l'adaptation du changement.
Est-ce important que la règle définie à l'heure x soit différente de la règle définie à l'heure y en raison de:
a) les gens d'affaires ne comprennent pas les affaires, ou;
b) les gens d'affaires ne comprennent pas les règles?
Je recommanderais fortement les moteurs de règles métier tels que Drools en tant que source ouvert ou moteur de règles commerciales tel que LiveRules.
- Lorsque vous avez beaucoup de stratégies d'entreprise qui sont de nature volatile, il est très difficile de maintenir cette partie du code de la technologie de base.
- Le moteur de règles offre une grande flexibilité du cadre et est facile à modifier et à déployer.
- Les moteurs de règles ne doivent pas être utilisés partout mais doivent l'être lorsque vous avez beaucoup de stratégies où les changements sont inévitables de façon régulière.