Quando NON dovresti usare un motore di regole? [chiuso]

Ho un elenco abbastanza decente dei vantaggi dell'utilizzo di un motore di regole, così come alcuni motivi per usarli, quello di cui ho bisogno è un elenco dei motivi per cui NON dovresti usare un motore di regole

Il meglio che ho finora è questo:

I motori di regole non sono realmente destinati a gestire il flusso di lavoro o le esecuzioni dei processi, né i motori di flusso di lavoro o gli strumenti di gestione dei processi sono progettati per fare le regole.

Qualche altro grande motivo per cui non dovresti usarli?

Divento molto nervoso quando vedo persone che usano set di regole molto grandi (ad esempio, dell'ordine di migliaia di regole in un singolo set di regole). Ciò accade spesso quando il motore delle regole è un singleton seduto al centro dell'azienda nella speranza che mantenere le regole DRY le renda accessibili a molte app che le richiedono. Sfiderei chiunque a dirmi che un motore di regole Rete con così tante regole è ben compreso. Non sono a conoscenza di strumenti che possano controllare per garantire che non esistano conflitti.

Penso che il set di regole di partizionamento per mantenerli piccoli sia un'opzione migliore. Gli aspetti possono essere un modo per condividere una serie di regole comuni tra molti oggetti.

Preferisco un approccio più semplice e basato sui dati laddove possibile.

Darò 2 esempi dall'esperienza personale in cui l'uso di un motore di regole è stata una cattiva idea, forse questo aiuterà: -

1. In un progetto precedente, ho notato che i file delle regole (il progetto utilizzava Drools) contenevano molto codice java, inclusi loop, funzioni ecc. Erano essenzialmente file java mascherati da file di regole. Quando ho chiesto all'architetto il suo ragionamento per il progetto, mi è stato risposto che "le regole non sono mai state pensate per essere mantenute dagli utenti aziendali".

Lezione : sono chiamate "regole aziendali" per un motivo, non utilizzare regole quando non è possibile progettare un sistema che possa essere facilmente mantenuto / compreso dagli utenti aziendali.

2. Un altro caso; Il progetto ha utilizzato le regole perché i requisiti erano mal definiti / compresi e cambiati spesso. La soluzione del team di sviluppo è stata quella di utilizzare le regole in modo estensivo per evitare frequenti distribuzioni di codice.

Lezione : i requisiti tendono a cambiare molto durante le modifiche alla versione iniziale e non garantiscono l'utilizzo delle regole. Usa le regole quando la tua attività cambia spesso (non i requisiti). Ad esempio: - Un software che fa le tue tasse cambierà ogni anno man mano che le leggi fiscali cambiano e l'uso delle regole è un'idea eccellente. La versione 1.0 di un'app Web cambierà spesso man mano che gli utenti identificano nuovi requisiti, ma si stabilizzerà nel tempo. Non utilizzare le regole come alternativa alla distribuzione del codice.

Sono un grande fan dei motori per regole di business, poiché possono aiutarti a semplificarti la vita come programmatore. Una delle prime esperienze che ho avuto mentre lavoravo a un progetto di Data Warehouse è stata trovare stored procedure contenenti complesse strutture CASE che si estendevano su intere pagine. È stato un incubo eseguire il debug, poiché era molto difficile capire la logica applicata in strutture CASE così lunghe e determinare se si verifica una sovrapposizione tra una regola a pagina 1 del codice e un'altra a pagina 5. Nel complesso, abbiamo avuto più di 300 di queste regole incorporate nel codice.

Quando abbiamo ricevuto un nuovo requisito di sviluppo, per qualcosa chiamato Accounting Destination, che prevedeva il trattamento di più di 3000 regole, sapevo che qualcosa doveva cambiare. Allora ho lavorato su un prototipo che in seguito è diventato il genitore di quello che ora è un motore di regole aziendali personalizzate, in grado di gestire tutti gli operatori standard SQL. Inizialmente abbiamo utilizzato Excel come strumento di creazione e, in seguito, abbiamo creato un'applicazione ASP.net che consentirà agli utenti aziendali di definire le proprie regole aziendali, senza la necessità di scrivere codice. Ora il sistema funziona correttamente, con pochissimi bug e contiene oltre 7000 regole per il calcolo di questa destinazione contabile. Non credo che tale scenario sarebbe stato possibile solo con l'hard-coding.

Tuttavia, ci sono dei limiti a tale approccio:

• È necessario disporre di utenti aziendali capaci che abbiano un'ottima conoscenza dell'attività aziendale.
• Esiste un carico di lavoro significativo sulla ricerca dell'intero sistema (nel nostro caso un Data Warehouse), al fine di determinare tutte le condizioni hard-coded che hanno senso tradurre in regole che devono essere gestite da un motore di regole di business. Abbiamo anche dovuto fare molta attenzione che questi modelli iniziali fossero completamente comprensibili per gli utenti aziendali.
• È necessario disporre di un'applicazione utilizzata per la creazione di regole, in cui vengono implementati algoritmi per il rilevamento delle regole di business sovrapposte. Altrimenti ti ritroverai con un gran casino, dove nessuno capisce più i risultati che ottengono. Quando si verifica un bug in un componente generico come un motore di regole aziendali personalizzato, può essere molto difficile eseguire il debug e richiedere test approfonditi per assicurarsi che le cose che funzionavano prima funzionino anche ora.

Maggiori dettagli su questo argomento possono essere trovati in un post che ho scritto: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

Nel complesso, il più grande vantaggio dell'utilizzo di un Business Rule Engine è che consente agli utenti di riprendere il controllo sulle definizioni e sull'authoring delle Business Rule, senza la necessità di andare al reparto IT ogni volta che devono modificare qualcosa. Inoltre, riduce il carico di lavoro sui team di sviluppo IT, che ora possono concentrarsi sulla creazione di cose con più valore aggiunto.

Saluti,

Nicolae

L'unico punto che ho notato essere "la spada a doppio taglio" è:

affidando la logica a personale non tecnico

Ho visto questo lavoro alla grande, quando hai uno o due geni multidisciplinari dal lato non tecnico, ma ho anche visto la mancanza di tecnicità che porta a gonfiare, più bug e in generale 4 volte il costo di sviluppo / manutenzione.

Quindi devi considerare seriamente la tua base di utenti.

Ho pensato che l'articolo di Alex Papadimoulis fosse abbastanza perspicace: http://thedailywtf.com/articles/soft_coding.aspx

Non è completo, ma ha dei buoni punti.

GRANDE articolo su quando non usare un motore di regole ... (così come quando usarne uno) ....

http://www.jessrules.com/guidelines.shtml

Un'altra opzione è che se si dispone di un insieme lineare di regole che si applicano solo una volta in qualsiasi ordine per ottenere un risultato, è creare un'interfaccia accattivante e chiedere agli sviluppatori di scrivere e distribuire queste nuove regole. Il vantaggio è che è incredibilmente veloce perché normalmente passeresti la sessione di ibernazione O la sessione jdbc e tutti i parametri in modo da avere accesso a tutti i dati delle tue app ma in modo efficiente. Con un elenco dei fatti, possono esserci molti loop / corrispondenze che possono davvero rallentare il sistema ..... È un altro modo per evitare un motore di regole ed essere in grado di essere distribuito dinamicamente (sì, le nostre regole fantastiche sono state implementate in un database e non abbiamo avuto ricorsività ... o ha soddisfatto la regola oppure no). È solo un'altra opzione ..... oh e un altro vantaggio non è l'apprendimento della sintassi delle regole per gli sviluppatori in arrivo.

Dipende davvero dal tuo contesto. Il motore di regole ha il suo posto e quanto sopra è solo un'altra opzione se hai regole su un progetto che potresti voler distribuire dinamicamente per situazioni molto semplificate che non richiedono un motore di regole.

FONDAMENTALMENTE NON usare un motore di regole se hai un semplice set di regole e puoi invece avere un'interfaccia fantastica ..... altrettanto dinamicamente distribuibile e nuovi sviluppatori che si uniscono al tuo team possono impararlo più velocemente del linguaggio sbavante. (Ma questa è la mia opinione)

Nella mia esperienza, i motori delle regole funzionano meglio quando quanto segue è vero:

1. Dottrina ben definita per il tuo dominio problematico
2. Dati di alta qualità (preferibilmente automatizzati) per guidare la maggior parte dei tuoi input
3. Accesso a esperti in materia
4. Sviluppatori di software con esperienza nella creazione di sistemi esperti

Se manca uno di questi quattro tratti, potresti comunque scoprire che un motore di regole funziona per te, ma ogni volta che l'ho provato con anche 1 mancante, ho avuto problemi.

Questo è sicuramente un buon inizio. L'altra cosa con i motori delle regole è che alcune cose sono ben comprese, deterministiche e dirette. La ritenuta sui salari è (o è usata per essere) così. Si potrebbe esprimere come regole che sarebbero risolti da un motore di regole, ma si potrebbe esprimere le stesse regole abbastanza semplice tabella di valori.

Quindi, i motori del flusso di lavoro sono utili quando si esprime un processo a lungo termine che avrà dati persistenti. I motori di regole possono fare una cosa simile, ma devi aggiungere molta complessità.

I motori di regole sono utili quando hai basi di conoscenza complicate e hai bisogno di ricerca. I motori di regole possono risolvere problemi complicati e possono essere adattati rapidamente a situazioni mutevoli, ma impongono molta complessità all'implementazione di base.

Molti algoritmi decisionali sono abbastanza semplici da essere espressi come un semplice programma basato su tabelle senza la complessità implicita da un vero motore di regole.

Consiglio vivamente motori di regole aziendali come Drools come open source o motore di regole commerciali come LiveRules.

• Quando si hanno molte politiche aziendali di natura volatile, è molto difficile mantenere quella parte del codice tecnologico di base.
• Il motore delle regole fornisce una grande flessibilità del framework e facile da modificare e distribuire.
• I motori di regole non devono essere utilizzati ovunque, ma devono essere utilizzati quando sono presenti molte politiche in cui le modifiche sono inevitabili su base regolare.

Non capisco davvero alcuni punti come:
a) gli uomini d'affari hanno bisogno di capire molto bene gli affari, o;
b) disaccordo sugli uomini d'affari non ha bisogno di conoscere la regola.

Per me, come persone che toccano semplicemente BRE ，, il vantaggio di BRE è così chiamato per consentire al sistema di adattarsi ai cambiamenti aziendali, quindi si concentra sull'adattamento del cambiamento.
Ha importanza se la regola impostata al tempo x è diversa dalla regola impostata al tempo y a causa di:
a) gli uomini d'affari non capiscono gli affari, o;
b) gli uomini d'affari non capiscono le regole?