Moteur de règles - avantages et inconvénients

Question

Je vérifie un projet qui utilise ce qu'on appelle un Moteur de règles . En bref, c'est un moyen d'externaliser la logique métier du code de l'application.

Ce concept est entièrement nouveau pour moi et je suis assez sceptique à son sujet. Après avoir entendu les gens parler de Modèles de domaine anémiques depuis quelques années, je remets en question l'approche du moteur de règles. Pour moi, ils semblent être un excellent moyen d'affaiblir un modèle de domaine. Par exemple, disons que je fais une application web Java qui interagit avec un moteur de règles. Ensuite, je décide que je veux avoir une application Android basée sur le même domaine. À moins que je ne veuille que l'application Android interagisse également avec le moteur de règles, je vais devoir faire l'impasse sur la logique métier déjà écrite.

Comme je n'ai pas encore d'expérience en la matière, par simple curiosité, j'aimerais connaître les avantages et les inconvénients de l'utilisation d'un moteur de règles ? Le seul avantage auquel je pense est que vous n'avez pas besoin de reconstruire l'ensemble de votre application juste pour changer une règle de gestion (mais vraiment, combien d'applications ont vraiment autant de changements ?) Mais l'utilisation d'un moteur de règles pour résoudre ce problème me donne l'impression de mettre un pansement sur une blessure par balle.

UPDATE - depuis que j'ai écrit ceci, le dieu lui-même, Martin Fowler, a a publié un blog sur l'utilisation d'un moteur de règles .

Answer 1

La plupart des moteurs de règles que j'ai vus sont considérés comme une boîte noire par le code système. Si je devais construire un modèle de domaine, je voudrais probablement que certaines règles métier soient intrinsèques au modèle de domaine, par exemple des règles métier qui me disent quand un objet a des valeurs invalides. Cela permet à plusieurs systèmes de partager le modèle de domaine sans dupliquer la logique métier. Je pourrais demander à chaque système d'utiliser le même service de règles pour valider mon modèle de domaine, mais cela semble affaiblir mon modèle de domaine (comme indiqué dans la question). Pourquoi ? Parce qu'au lieu d'appliquer mes règles métier de manière cohérente dans tous les systèmes et à tout moment, je m'en remets aux programmeurs des systèmes pour déterminer quand les règles métier doivent être appliquées (en appelant le service de règles). Ce n'est peut-être pas un problème si le modèle de domaine vous est livré complètement rempli, mais cela peut être problématique si vous avez affaire à une interface utilisateur ou à un système qui modifie les valeurs du modèle de domaine au cours de sa durée de vie.

Il existe une autre catégorie de règles métier : la prise de décision. Par exemple, une compagnie d'assurance peut avoir besoin de classer le risque de la souscription d'un candidat et d'arriver à une prime. Vous pourriez placer ces types de règles métier dans votre modèle de domaine, mais une décision centralisée pour des scénarios comme celui-ci est généralement souhaitable et, en fait, s'intègre très bien dans une architecture orientée services. Cela soulève la question de savoir pourquoi un moteur de règles et non un code système. L'endroit où un moteur de règles peut être un meilleur choix est lorsque les règles métier responsables de la décision changent au fil du temps (comme certaines autres réponses l'ont souligné).

Les moteurs de règles vous permettent généralement de modifier les règles sans redémarrer votre système ou déployer un nouveau code exécutable (quelles que soient les promesses d'un fournisseur, veillez à tester vos modifications dans un environnement de non-production car, même si le moteur de règles est irréprochable, des humains continuent de modifier les règles). Si vous vous dites : "Je peux faire cela en utilisant une base de données pour stocker les valeurs qui changent", vous avez raison. Un moteur de règles n'est pas une boîte magique qui fait quelque chose de nouveau. Il s'agit d'un outil qui fournit un niveau d'abstraction plus élevé afin que vous puissiez moins vous concentrer sur la réinvention de la roue. De nombreux fournisseurs vont encore plus loin en vous permettant de créer des modèles afin que les utilisateurs professionnels puissent remplir les blancs au lieu d'apprendre un langage de règles.

Une dernière mise en garde concernant les modèles : les modèles ne prendront jamais moins de temps que la rédaction d'une règle sans modèle, car le modèle doit, au minimum, décrire la règle. Prévoyez un coût initial plus élevé (comme si vous construisiez un système utilisant une base de données pour stocker des valeurs qui changent, au lieu d'écrire les règles directement dans le code système) - le retour sur investissement est dû au fait que vous économisez sur la maintenance future du code système.

Answer 2

Je pense que vos préoccupations concernant les modèles de domaine anémiques sont valables.

J'ai vu deux applications d'un moteur de règles Rete commercial bien connu fonctionner en production là où je travaille. Je considère l'une comme un succès et l'autre comme un échec.

L'application réussie est une application d'arbre de décision, composée de ~10 arbres de ~30 points de branchement chacun. Le moteur de règles possède une interface utilisateur qui permet aux professionnels de gérer les règles.

L'application la moins réussie a ~3000 règles introduites dans une base de données de règles. Personne n'a la moindre idée de l'existence de règles conflictuelles lorsqu'une nouvelle règle est ajoutée. L'algorithme de Rete est peu compris et l'expertise du produit a quitté l'entreprise. Il est donc devenu une boîte noire, intouchable et irréfacturable. Le cycle de déploiement est toujours affecté par les changements de règles - un test de régression complet doit être effectué lorsque les règles sont modifiées. La mémoire est également un problème.

Je ferais preuve de prudence. Lorsqu'un ensemble de règles est de taille modeste, il est facile de comprendre les changements, comme l'exemple simpliste d'e-mail donné ci-dessus. Lorsque le nombre de règles atteint des centaines, je pense que vous pourriez avoir un problème.

Je m'inquiéterais également de voir un moteur de règles devenir un goulot d'étranglement singleton dans votre application.

Je ne vois rien de mal à utiliser des objets comme moyen de partitionner l'espace du moteur de règles. Intégrer un comportement dans des objets qui s'en remettent à un moteur de règles privé me semble correct. Vous rencontrerez des problèmes lorsque le moteur de règles aura besoin d'un état qui ne fait pas partie de son objet pour fonctionner correctement. Mais c'est juste un autre exemple de la difficulté de la conception.

Answer 3

Les moteurs de règles peuvent offrir beaucoup de valeur, dans certains cas.

Tout d'abord, de nombreux moteurs de règles fonctionnent de manière plus déclarative. Un exemple très rudimentaire serait AWK, où vous pouvez assigner des regex à des blocs de code. Lorsque la regex est vue par l'analyseur de fichiers, le bloc de code est exécuté.

Vous pouvez voir que dans ce cas, si vous avez, disons, un grand fichier AWK et que vous voulez ajouter encore une autre "règle", vous pouvez facilement aller au bas du fichier, ajouter votre regex et votre logique, et en avoir terminé. Plus précisément, pour de nombreuses applications, vous n'êtes pas particulièrement concerné par ce que font les autres règles, et les règles n'interagissent pas vraiment les unes avec les autres.

Ainsi, le fichier AWK ressemble davantage à une "soupe de règles". Cette nature de "soupe de règles" permet aux gens de se concentrer très étroitement sur leur domaine sans se soucier de toutes les autres règles qui peuvent se trouver dans le système.

Par exemple, Frank est intéressé par les commandes dont le montant total est supérieur à 1000 $, il indique donc dans le système de règles qu'il est intéressé. "IF order.total > 1000 THEN email Frank".

Pendant ce temps, Sally veut que toutes les commandes proviennent de la côte ouest : "IF order.source == 'WEST_COAST' THEN email Sally".

Vous pouvez donc constater, dans ce cas trivial et artificiel, qu'un ordre peut satisfaire aux deux règles, tout en étant indépendant l'un de l'autre. Une commande de 1200$ provenant de la côte ouest notifie à la fois Frank et Sally. Lorsque Frank ne sera plus concerné, il sortira simplement sa règle de la soupe.

Dans de nombreuses situations, cette flexibilité peut s'avérer très puissante. Elle peut aussi, comme dans ce cas, être exposée aux utilisateurs finaux pour des règles simples. En utilisant des expressions de haut niveau et peut-être des scripts légers.

Il est clair que dans un système compliqué, toutes sortes de relations peuvent se produire, et c'est pourquoi le système tout entier n'est pas "fait avec des règles". Quelqu'un, quelque part, sera chargé de veiller à ce que les règles ne deviennent pas incontrôlables. Mais cela ne diminue pas nécessairement la valeur qu'un tel système peut apporter.

Sans parler des systèmes experts, où les règles s'appuient sur des données que les règles peuvent créer, mais un système de règles plus simple.

Quoi qu'il en soit, j'espère que cet exemple montre comment un système de règles peut contribuer à renforcer une application plus vaste.

Answer 4

Le plus grand avantage que j'ai vu pour les moteurs de règles est qu'ils permettent aux propriétaires de règles d'affaires de mettre en œuvre les règles d'affaires, au lieu de faire porter le fardeau aux programmeurs. Même si vous disposez d'un processus agile dans lequel vous obtenez constamment un retour d'information de la part des parties prenantes et que vous procédez à des itérations rapides, vous n'atteindrez pas le niveau d'efficacité qui peut être atteint si les personnes qui élaborent les règles métier les mettent également en œuvre.

De même, on ne saurait sous-estimer l'intérêt de supprimer le cycle recompilation-retest-redéploiement qui peut résulter d'un simple changement de règle, si les règles sont intégrées au code. Il y a souvent plusieurs équipes qui sont impliquées dans la mise en place de la bénédiction sur un build, et l'utilisation d'un moteur de règles peut rendre une grande partie de cela inutile.

Answer 5

J'ai écrit un moteur de règles pour un client. La plus grande victoire a été d'inclure toutes les parties prenantes. Le moteur pouvait exécuter (ou rejouer) une requête et expliquer ce qui se passait en texte. Les responsables métier pouvaient regarder la description textuelle et signaler rapidement les nuances dans les règles, les exceptions et autres cas particuliers. Une fois que l'aspect commercial a été impliqué, la validation s'est améliorée car il était facile d'obtenir leur contribution. En outre, le moteur de règles peut vivre séparément des autres parties de la base de code d'une application, de sorte que vous pouvez l'utiliser dans plusieurs applications.

L'inconvénient est que certains programmeurs n'aiment pas trop apprendre. Les moteurs de règles et les règles qu'ils contiennent, ainsi que le matériel qui les met en œuvre, peuvent être un peu difficiles. Bien qu'un bon système puisse facilement gérer des réseaux de logique (ou d'illogique, souvent ;) malades et tordus, ce n'est pas aussi simple que de coder un tas de règles et de règles. if (peu importe ce que font certains moteurs de règles simples d'esprit). Le moteur de règles vous donne les outils nécessaires pour gérer les relations entre les règles, mais vous devez encore être capable d'imaginer tout cela dans votre esprit. Parfois, c'est comme vivre dans le film Brésil . :)