Moteur de règles - avantages et inconvénients

Question

J'audite un projet utilisant un moteur de règles . En bref, il s'agit d'un moyen d'extérioriser la logique métier à partir du code d'application.

Ce concept est entièrement nouveau pour moi et je suis assez sceptique à ce sujet. Après avoir entendu les gens parler des Modèles de domaine anémique au cours des dernières années, Approche du moteur de règles. Pour moi, ils semblent être un excellent moyen de FAIBLIR un modèle de domaine. Par exemple, disons que je fais une application Web java en interaction 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 aussi que l'application Android interagisse avec le moteur de règles, je vais devoir passer à côté de la logique commerciale déjà écrite.

Comme je n’ai encore aucune expérience avec eux, juste par curiosité, j’étais intéressé d’entendre parler des avantages et des inconvénients de l’utilisation d’un moteur de règles? Le seul avantage auquel je puisse penser est qu'il n'est pas nécessaire de reconstruire toute votre application simplement pour changer une règle de gestion (mais vraiment, combien d'applications ont réellement autant de changements?). Mais utiliser un moteur de règles pour résoudre ce problème me semble un peu comme mettre un pansement sur une plaie de fusil de chasse.

UPDATE - depuis l’écriture de cet article, le dieu lui-même, Martin Fowler, 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 construisais un modèle de domaine, je souhaiterais probablement que certaines règles métier soient intrinsèques au modèle de domaine, par exemple. 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 systématiquement mes règles métier sur tous les systèmes, je compte sur les programmeurs système pour déterminer à quel moment les règles métier doivent être appliquées (en appelant le service de règles). Cela peut ne pas poser de problème si le modèle de domaine vous est entièrement rempli, mais si vous utilisez 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 classe de règles commerciales: la prise de décision. Par exemple, une compagnie d’assurance peut avoir besoin de classer le risque de souscription d’un demandeur et d’obtenir une prime. Vous pouvez placer ces types de règles métier dans votre modèle de domaine, mais une décision centralisée pour ce type de scénario est généralement souhaitable et s'intègre parfaitement dans une architecture orientée service. Cela pose la question de savoir pourquoi un moteur de règles et non un code système. Le moteur de règles peut constituer un meilleur choix lorsque les règles métier responsables de la décision changent avec le temps (comme l'ont souligné d'autres réponses).

Les moteurs de règles vous permettent généralement de modifier les règles sans redémarrer votre système ni déployer de nouveaux codes exécutables (quelles que soient les promesses que vous recevez d'un fournisseur, assurez-vous de tester vos modifications dans un environnement hors production, car même si la règle moteur est sans faille, les humains changent encore les règles). Si vous pensez: "Je peux le faire 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 offrant un niveau d’abstraction plus élevé afin que vous puissiez vous concentrer moins 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.

Mise en garde concernant les modèles: les modèles ne peuvent jamais prendre moins de temps que l’écriture d’une règle sans modèle, car le modèle doit au minimum décrire la règle. Planifiez un coût initial plus élevé (comme si vous construisiez un système utilisant une base de données pour stocker les valeurs qui changent par rapport à l'écriture des 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émique sont valides.

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

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

L'application moins réussie a environ 3000 règles claquées dans une base de données de règles. Personne n'a la moindre idée s'il existe des règles contradictoires lors de l'ajout d'une nouvelle. L'algorithme Rete est peu compris et l'expertise acquise avec le produit a quitté l'entreprise. Elle est donc devenue une boîte noire intouchable et irréfutable. Le cycle de déploiement est toujours affecté par les modifications des règles - un test de régression complet doit être effectué lorsque les règles sont modifiées. La mémoire était aussi un problème.

Je marcherais légèrement. Lorsqu'un jeu de règles est de taille modeste, il est facile de comprendre les modifications, comme l'exemple de courrier électronique simpliste présenté ci-dessus. Une fois que le nombre de règles atteindra des centaines, je pense que vous pourriez avoir un problème.

Je crains également qu'un moteur de règles ne devienne un goulet d'étranglement de singleton dans votre application.

Je ne vois aucun inconvénient à utiliser des objets pour partitionner cet espace moteur. L'intégration du comportement dans des objets qui se rapportent à un moteur de règles privé me semble acceptable. Les problèmes vous toucheront lorsque le moteur de règles requiert que l'état ne fasse pas partie de son objet pour qu'il se déclenche correctement. Mais c’est là un autre exemple de conception difficile.

Answer 3

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

Premièrement, de nombreux moteurs de règles fonctionnent de manière plus déclarative. AWK est un exemple très grossier, dans lequel vous pouvez affecter des expressions rationnelles à des blocs de code. Lorsque le regex est vu par l'analyseur de fichiers, le bloc de code est exécuté.

Vous pouvez constater que, dans ce cas, si vous disposiez d'un fichier AWK volumineux et que vous souhaitiez ajouter encore une autre "règle", vous pouvez facilement aller au bas du fichier, ajouter votre expression rationnelle et logique, et en finir avec ça. En particulier, pour de nombreuses applications, vous ne vous préoccupez pas particulièrement de ce que font les autres règles et celles-ci n'interopèrent pas vraiment.

Le fichier AWK ressemble donc davantage à un "soupe aux règles". Cette "soupe de règles" La nature permet aux gens de se concentrer très étroitement sur leur domaine sans se soucier des autres règles pouvant figurer dans le système.

Par exemple, Frank s'intéresse aux commandes d'un montant total supérieur à 1 000 dollars. Il ajoute donc au système de règles qui l'intéresse. " SI commande.total > 1000 THEN envoyez un courriel à Frank ".

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

Ainsi, dans ce cas trivial et artificiel, vous pouvez constater qu’un ordre peut satisfaire les deux règles, mais que ces deux règles sont indépendantes l’une de l’autre. Une commande de 1200 $ de la côte ouest en informe Frank et Sally. Quand Frank n’a plus rien à faire, il supprimera tout simplement son cas.

Dans de nombreuses situations, cette flexibilité peut être très puissante. Comme ce cas, il peut également être exposé aux utilisateurs finaux pour des règles simples. Utiliser des expressions de haut niveau et peut-être des scripts légers.

Maintenant, à l’évidence, dans un système complexe, il peut y avoir toutes sortes d’interrelations, c’est pourquoi le système tout entier n’est pas "Terminé avec des règles". Quelqu'un, quelque part, sera responsable du respect des règles. Mais cela ne diminue pas nécessairement la valeur qu'un tel système peut fournir.

Remarquez que cela ne concerne même pas les systèmes experts, où les règles sont déclenchées par les 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 aider à étendre une application plus volumineuse.

Answer 4

Le plus gros avantage que j'ai constaté pour les moteurs de règles est qu'il permet aux propriétaires de règles métier d'implémenter les règles métier au lieu d'imposer la responsabilité aux programmeurs. Même si vous avez un processus agile dans lequel vous recevez constamment les réactions des parties prenantes et que vous parcourez des itérations rapides, il ne sera pas possible d'atteindre le niveau d'efficacité qui peut être atteint si les personnes chargées de définir les règles métier les implémentaient également.

De même, vous ne pouvez pas sous-estimer la valeur de la suppression du cycle de recompilation-retestage-redéploiement pouvant résulter d'un simple changement de règle, si les règles sont incorporées dans du code. Plusieurs équipes sont souvent impliquées dans la génération de la bénédiction, et l’utilisation d’un moteur de règles peut rendre inutile une bonne partie de cette tâche.

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 peut exécuter (ou rejouer) une requête et expliquer ce qui se passe dans le texte. Les gens d’affaires pourraient consulter la description et signaler rapidement les nuances dans les règles, les exceptions et d’autres cas particuliers. Une fois que les entreprises ont été impliquées, la validation s’est beaucoup améliorée car il était facile d’obtenir leurs commentaires. De plus, le moteur de règles peut vivre séparément des autres parties d’une base de code d’application, ce qui vous permet de l’utiliser dans toutes les applications.

Le problème est que certains programmeurs n'aiment pas trop apprendre. Les moteurs de règles et les règles que vous y mettez, ainsi que les éléments qui les implémentent, peuvent être un peu poilus. Bien qu'un bon système puisse facilement gérer des réseaux logiques malades et tordus (ou souvent illogiques;), ce n'est pas aussi simple que de coder un ensemble d'instructions si (quels que soient les moteurs de règles simples) faire). Le moteur de règles vous donne les outils nécessaires pour gérer les relations entre règles, mais vous devez tout de même pouvoir imaginer tout cela dans votre esprit. Parfois, c’est comme vivre dans le film Brésil . :)

Answer 6

Cela dépend (comme tout le reste) de votre application. Pour certaines applications (généralement celles qui ne changent jamais ou les règles qui s'appliquent le mieux aux constantes réelles, c'est-à-dire qui ne changeront pas de façon notable, par exemple les propriétés physiques et les formules), l'utilisation d'un moteur de règles n'a aucun sens. introduit une complexité supplémentaire et nécessite que le développeur dispose d'un ensemble de compétences plus étendu.

Pour d’autres applications, c’est vraiment une bonne idée. Prenons, par exemple, le traitement des commandes (commandes allant de la facturation au traitement des transactions en devise), de temps en temps, une loi ou un code pertinent (au sens judiciaire) est modifié, ce qui vous oblige à remplir une nouvelle exigence (par exemple, la taxe de vente , un classique). Plutôt que d'essayer de forcer votre ancienne application dans cette nouvelle situation dans laquelle vous devez tout à coup penser à la taxe de vente, alors qu'avant, il est plus facile d'adapter votre jeu de règles plutôt que de devoir vous mêler potentiellement d'un grand ensemble de votre code.

Ensuite, le prochain amendement de votre gouvernement local exige la déclaration de toutes les ventes dans le respect de certains critères, au lieu de vous obliger à ajouter cela également. En fin de compte, vous obtiendrez un code très complexe qu'il sera assez difficile de gérer lorsque vous vous retournerez et que vous voudrez rétablir l'effet de l'une des règles, sans influencer toutes les autres ...

Answer 7

Jusqu'à présent, tout le monde s'est montré très positif à propos des moteurs de règles, mais je conseille au lecteur de se méfier. Lorsqu'un problème devient un peu plus compliqué, vous pouvez soudainement constater que tout un moteur de règles a été rendu inapproprié ou bien plus compliqué que dans un langage plus puissant. En outre, pour de nombreux problèmes, les moteurs de règles ne pourront pas détecter facilement les propriétés qui réduisent considérablement l'empreinte d'exécution et de mémoire associée à l'évaluation de la condition. Il existe relativement peu de situations dans lesquelles je préférerais un moteur de règles à un framework d'injection de dépendance ou à un langage de programmation plus dynamique.

Answer 8

"mais vraiment, combien d'applications ont réellement autant de modifications?"

Honnêtement, chaque application sur laquelle j'ai travaillé a subi de sérieux changements de flux de travail et / ou de logique, du concept à bien après son déploiement. C’est la raison numéro un pour la "maintenance". programmation ...

La réalité est que vous ne pouvez pas tout penser à l’avance, d’où la raison des processus Agiles. De plus, les BA semblent toujours passer à côté de quelque chose de vital jusqu'à ce qu'on le trouve dans les tests.

Les moteurs de règles vous obligent à séparer véritablement la logique métier de la présentation et du stockage. De plus, si vous utilisez le bon moteur, votre BA peut ajouter et supprimer de la logique si nécessaire. Comme l’a dit Chris Marasti-Georg, il incombe à la BA. Mais plus que cela, cela permet à la BA d’obtenir exactement ce qu’elle demande.

Answer 9

Un moteur de règles est une solution gagnante pour une application configurable dans laquelle vous ne souhaitez pas créer de builds personnalisés s'il est possible de l'éviter. Ils sont également doués pour centraliser de grandes bases de règles et d’algorithmes tels que Rete sont efficaces pour une correspondance rapide avec grands ensembles de règles.

Answer 10

Beaucoup de bonnes réponses déjà, mais je voulais ajouter quelques choses:

1. dans l’automatisation d’une décision de toute complexité, l’essentiel devient rapidement votre capacité à gérer plutôt qu’à exécuter la logique impliquée. Un moteur de règles n’aidera pas à résoudre ce problème. Vous devez réfléchir aux fonctionnalités de gestion des règles dont dispose un système de gestion des règles métier. La plupart des moteurs de règles commerciaux et open source ont évolué vers des systèmes de gestion de règles avec référentiels, rendant compte de l'utilisation des règles, de la gestion des versions, etc. Un référentiel de règles, structuré en ensembles de règles cohérents pouvant être orchestrés pour prendre des décisions commerciales des milliers de lignes de code ou une soupe de règles.
2. Il existe de nombreuses façons d'utiliser une approche déclarative basée sur des règles. L'utilisation de règles pour gérer une interface utilisateur ou dans le cadre de la définition d'un processus peut s'avérer très efficace. Cependant, l'utilisation la plus utile d'une approche basée sur des règles est d'automatiser les décisions de l'entreprise et de la fournir sous forme de services de décision faiblement couplés, qui prennent des entrées, exécutent des règles et renvoient une réponse - une décision. En tant que services répondant à des questions concernant d’autres services tels que "ce client présente-t-il un bon risque de crédit" ou "quelle réduction dois-je accorder à ce client pour cette commande ou" quelle est la meilleure vente croisée pour ce client à ce moment. Ces services de décision peuvent être très efficacement construits à l’aide d’un système de gestion des règles et permettre une intégration aisée de l’analyse dans le temps, ce dont de nombreuses décisions bénéficient.

Answer 11

Je considère que les moteurs de règles, de processus et de données (bases de données a.k.a.) sont essentiellement similaires. Mais, pour une raison quelconque, nous ne disons jamais que le blackboxing du sous-système de persistance est mauvais.

Deuxièmement, d'après mon point de vue, un modèle anémique n'est pas un modèle léger dans la mise en œuvre des comportements, mais un modèle léger dans les comportements eux-mêmes . La méthode qui décrit un comportement disponible dans un objet de modèle de domaine ne doit pas nécessairement être effectuée par l'objet lui-même.

Answer 12

La plus grande complexité de mon expérience des moteurs de règles est la suivante:

1. de POOP POV, il est très difficile de refactoriser et de tester les règles écrites dans un langage déclaratif pendant que vous refactorisez le code qui les affecte.
2. Souvent, nous devrions toujours penser à l'ordre d'exécution des règles qui se transforme en fouillis quand il y en a beaucoup.
3. Certaines modifications mineures peuvent entraîner un comportement incorrect des règles conduisant à des bogues de production. En pratique, il n’est pas toujours possible de couvrir tous les cas avec des tests préalables.
4. Les objets en mutation de règles utilisés dans d'autres objets augmentent également la complexité, ce qui oblige les développeurs à les diviser en étapes.