La décision d'exposer ou non une interface permettant au personnel non technique de modifier les règles métier dépend en grande partie de plusieurs facteurs, notamment les objectifs du projet, le coût du projet, la durée de vie du projet et le rapport des connus aux inconnus dans le projet.
Par exemple, si je pensais que personne n'utiliserait l'interface de règles, je choisirais probablement de ne pas l'implémenter. Cependant, si j'avais des raisons de croire que les changements seraient fréquents et que différents utilisateurs finaux s'attendraient à ce que différentes règles soient en place, alors j'envisagerais de travailler à la création d'une telle fonctionnalité.
J'ai choisi de le faire sur un projet, et il a fallu des années avant que la fonctionnalité ne soit largement utilisée. Je soupçonnais que nous aurions éventuellement des utilisateurs finaux qui voudraient personnaliser les choses eux-mêmes, nous avons donc implémenté cette fonctionnalité en plusieurs parties.
Cela a commencé comme quelque chose que seules certaines personnes, comme les développeurs ou les administrateurs, pouvaient utiliser. L'interface était maladroite, mais utilisable si vous saviez ce que vous faisiez. Mais au moment où le produit était presque terminé, la logique du moteur de règles était utile, et notre équipe de conception lui a donné une belle interface utilisateur orientée client.
Si je devais le faire différemment, je pourrais choisir une architecture de base de données différente simplement parce que la courbe d'apprentissage est élevée. Mais en bref, le construire tôt a conduit à de nombreuses fonctionnalités destinées aux clients plus tard, sans les maux de tête d'avoir à revenir dans le code et à le refactoriser pour inclure toutes les règles dynamiques.