Moteur de règles - avantages et inconvénients
J'audite un projet qui utilise ce qu'on appelle un moteur de règles . En bref, il s'agit d'un moyen d'externaliser 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 de Modèles de domaine anémique depuis quelques années, je remets en question l’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 pas encore d'expérience avec eux, juste par curiosité, j'ai été intéressé par les avantages et les 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 pour changer certaines règles de gestion (mais combien d'applications ont réellement autant de modifications?). 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 blogué sur l’utilisation d’un moteur de règles .
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 peut être problématique 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 être le meilleur choix lorsque les règles métier responsables de la décision changent avec le temps (comme l'ont indiqué 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 le moteur de règles 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.
Un dernier avertissement 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 .
Je pense que vos préoccupations concernant les modèles de domaine anémique sont valables.
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 la 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 individuel dans votre application.
Je ne vois rien de mal à utiliser des objets comme un moyen de 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 vont vous frapper lorsque le moteur de règles requiert un état ne faisant pas partie de son objet pour qu'il se déclenche correctement. Mais ce n'est qu'un autre exemple de conception difficile.
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 voir que dans ce cas, si vous aviez, par exemple, un gros fichier AWK et que vous vouliez ajouter encore une autre "règle", vous pouvez facilement aller au bas du fichier, ajouter votre regex et votre logique, et terminer avec il. En particulier, pour de nombreuses applications, vous n'êtes pas particulièrement préoccupé par ce que font les autres règles, et ces règles n'interopèrent pas vraiment les unes avec les autres.
Ainsi, le fichier AWK devient plus une "règle soupe". Cette nature de "règles" permet aux utilisateurs 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 est intéressé par les commandes de plus de 1 000 dollars. Il ajoute donc au système de règles qui l'intéresse. "SI le total de la commande> 1000 ALORS, envoyez un courriel à Frank".
En attendant, Sally veut toutes les commandes de la côte ouest: "IF order.source == 'WEST_COAST' THEN email Sally".
Ainsi, vous pouvez voir dans ce cas trivial et artificiel, qu’un ordre peut satisfaire les deux règles, mais que les 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 simplement son cas de la soupe.
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.
De toute évidence, dans un système compliqué, 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 à développer une application plus volumineuse.
Le plus grand avantage que j'ai jamais vu pour les moteurs de règles est qu'il permet aux propriétaires de règles métier de mettre en œuvre les règles métier, au lieu de laisser la responsabilité aux programmeurs. Même si vous avez un processus agile dans lequel vous recevez constamment des commentaires des parties prenantes et passez rapidement à travers des itérations, 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.
En outre, vous ne pouvez pas sous-estimer la valeur de la suppression du cycle de recompilation-test-redéploiement qui peut 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 en faire une partie inutile.
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.
L'inconvénient 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 if (quels que soient les moteurs de règles simples). 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 . :)
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 oblige le développeur à disposer 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 exige que vous remplissiez une nouvelle exigence , un classique)… .. Plutôt que d'essayer de forcer votre ancienne application dans cette nouvelle situation où tout d'un coup vous devez penser à la taxe de vente, alors qu'avant, il est plus facile d'adapter votre jeu de règles que de avoir à se mêler potentiellement dans un grand ensemble de votre code.
Ensuite, le prochain amendement de votre gouvernement local exige la déclaration de toutes les ventes correspondant à certains critères, plutôt que de vous obliger à les ajouter. 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 ...
Jusqu'ici, 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 complexe 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 cadre d'injection de dépendance ou à un langage de programmation plus dynamique.
"Mais vraiment, combien d'applications ont vraiment autant de changements?"
Honnêtement, chaque application sur laquelle j'ai travaillé a subi d'importants 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 programmation "maintenance" ...
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'ils se retrouvent 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.
Beaucoup de bonnes réponses déjà, mais je voulais ajouter quelques choses:
- en automatisant une décision de n'importe quelle 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é pour devenir des systèmes de gestion de règles avec référentiels, rapports sur l'utilisation des règles, 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, est beaucoup plus simple à gérer. des milliers de lignes de code ou une soupe de règles.
- 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 remise 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 permettent d’intégrer facilement l’analyse dans le temps, ce dont de nombreuses décisions bénéficient.
Un moteur de règles est une solution gagnante pour une application configurable dans laquelle vous ne souhaitez pas avoir à créer de versions personnalisées si cela peut être évité. Ils sont également efficaces pour centraliser de grandes bases de règles et des algorithmes tels que Rete sont efficaces pour la mise en correspondance rapide avec de grands ensembles de règles.
Je considère que les moteurs de règles, de processus et de données (bases de données.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 de 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.
La plus grande complexité de mon expérience avec les moteurs de règles est la suivante:
- À partir de OOP POV, il est très difficile de refactoriser et de tester les règles écrites dans un langage déclaratif pendant que vous modifiez le code qui les affecte.
- Souvent, nous devrions toujours penser à l'ordre d'exécution des règles, qui se transforme en désordre lorsqu'il y en a beaucoup.
- Certaines modifications mineures peuvent entraîner un comportement incorrect des règles entraînant des bogues de production. En pratique, il n'est pas toujours possible de couvrir tous les cas avec des tests préalables.
- Les règles qui mutent des objets utilisés dans d'autres augmentent également la complexité, obligeant les développeurs à les diviser en étapes.