Rules Engine - pro e contro

Question

Sto audendo un progetto che utilizza quello che viene chiamato Engine delle regole . In breve, è un modo per esternalizzare la logica aziendale dal codice dell'applicazione.

Questo concetto è completamente nuovo per me e sono piuttosto scettico al riguardo. Dopo aver ascoltato le persone parlare di Anemic Domain Models negli ultimi anni, sto mettendo in discussione il Approccio al motore delle regole. A me sembrano un ottimo modo per WEAKEN un modello di dominio. Ad esempio, dico che sto realizzando una webapp Java che interagisce con un motore delle regole. Quindi decido di voler avere un'app Android basata sullo stesso dominio. A meno che non desideri che anche l'app Android interagisca con il motore delle regole, mi perderò la logica aziendale già scritta.

Dato che non ho ancora alcuna esperienza con loro, solo curiosità, ero interessato a conoscere i pro ei contro nell'uso di un motore delle regole? L'unico pro a cui riesco a pensare è che non è necessario ricostruire l'intera applicazione solo per modificare alcune regole aziendali (ma davvero, quante app hanno davvero tante modifiche?). Ma usare un motore delle regole per risolvere quel tipo di suono mi sembra come mettere un cerotto su una ferita da fucile.

AGGIORNAMENTO: da quando ha scritto questo, il dio stesso, Martin Fowler, ha blog sull'uso di un motore di regole .

Answer 1

La maggior parte dei motori di regole che ho visto sono visti come una scatola nera dal codice di sistema. Se dovessi costruire un modello di dominio, probabilmente vorrei che alcune regole aziendali fossero intrinseche al modello di dominio, ad es. regole commerciali che indicano quando un oggetto ha valori non validi. Ciò consente a più sistemi di condividere il modello di dominio senza duplicare la logica aziendale. Potrei avere ciascun sistema che utilizza lo stesso servizio di regole per convalidare il mio modello di dominio, ma questo sembra indebolire il mio modello di dominio (come è stato sottolineato nella domanda). Perché? Perché invece di applicare costantemente le mie regole di business su tutti i sistemi in ogni momento, mi affido ai programmatori di sistema per determinare quando devono essere applicate le regole di business (chiamando il servizio delle regole). Questo potrebbe non essere un problema se il modello di dominio viene popolato completamente, ma può essere problematico se hai a che fare con un'interfaccia utente o un sistema che modifica i valori nel modello di dominio nel corso della sua vita.

Esiste un'altra classe di regole aziendali: il processo decisionale. Ad esempio, una compagnia di assicurazioni potrebbe dover classificare il rischio di sottoscrivere un richiedente e arrivare a un premio. Potresti inserire questi tipi di regole aziendali nel tuo modello di dominio, ma una decisione centralizzata per scenari come questo di solito è auspicabile e, in realtà, si adatta abbastanza bene a un'architettura orientata ai servizi. Questo pone la domanda sul perché un motore di regole e non un codice di sistema. Il luogo in cui un motore di regole può essere una scelta migliore è quello in cui le regole aziendali responsabili della decisione cambiano nel tempo (come hanno indicato alcune altre risposte).

I motori di regole in genere ti consentono di modificare le regole senza riavviare il sistema o distribuire un nuovo codice eseguibile (indipendentemente dalle promesse che ricevi da un fornitore, assicurati di testare le modifiche in un ambiente non di produzione perché, anche se la regola il motore è impeccabile, gli umani stanno ancora cambiando le regole). Se stai pensando, "posso farlo utilizzando un database per archiviare i valori che cambiano", hai ragione. Un motore di regole non è una scatola magica che fa qualcosa di nuovo. È pensato per essere uno strumento che fornisce un livello più elevato di astrazione in modo da poterti concentrare meno sul reinventare la ruota. Molti fornitori fanno un ulteriore passo in avanti consentendo di creare modelli in modo che gli utenti aziendali possano riempire gli spazi vuoti invece di imparare una lingua delle regole.

Un avvertimento parziale sui modelli: i modelli non possono mai richiedere meno tempo rispetto alla scrittura di una regola senza un modello perché il modello deve, al minimo, descrivere la regola. Pianifica un costo iniziale più elevato (lo stesso che se dovessi costruire un sistema che utilizzava un database per archiviare i valori che cambiano rispetto alla scrittura delle regole direttamente nel codice di sistema): il ROI è dovuto al risparmio sulla manutenzione futura del codice di sistema .

Answer 2

Penso che le tue preoccupazioni sui modelli di dominio anemico siano valide.

Ho visto due applicazioni di un noto motore di regole di rete commerciale in esecuzione in produzione dove lavoro. Considererei uno un successo e l'altro un fallimento.

L'applicazione di successo è un'app ad albero decisionale, composta da ~ 10 alberi di ~ 30 punti di derivazione ciascuno. Il motore delle regole ha un'interfaccia utente che consente agli uomini d'affari di mantenere le regole.

L'applicazione di minor successo ha ~ 3000 regole bloccate in un database di regole. Nessuno ha idea se ci sono regole contrastanti quando ne viene aggiunta una nuova. C'è poca comprensione dell'algoritmo di Rete e la competenza con il prodotto ha lasciato l'azienda, quindi è diventata una scatola nera che è intoccabile e insostituibile. Il ciclo di distribuzione è ancora influenzato dalle modifiche alle regole: quando le regole vengono modificate è necessario eseguire un test di regressione completo. Anche la memoria era un problema.

Avrei camminato leggermente. Quando una serie di regole ha dimensioni modeste, è facile comprendere le modifiche, come il semplice esempio di posta elettronica riportato sopra. Una volta che il numero di regole sale a centinaia, penso che potresti avere un problema.

Mi preoccuperei anche che un motore di regole diventi un collo di bottiglia singleton nella tua applicazione.

Non vedo nulla di male nell'usare gli oggetti come un modo per partizionare lo spazio del motore delle regole. Incorporare il comportamento in oggetti che rimandano a un motore di regole privato mi sembra a posto. I problemi ti colpiranno quando il motore delle regole richiede uno stato che non fa parte del suo oggetto per funzionare correttamente. Ma questo è solo un altro esempio di design difficile.

Answer 3

I motori di regole possono offrire molto valore, in alcuni casi.

Innanzitutto, molti motori di regole funzionano in modo più dichiarativo. Un esempio molto grezzo potrebbe essere AWK, in cui è possibile assegnare regex a blocchi di codice. Quando il regex viene visto dal file scanner, viene eseguito il blocco di codice.

Puoi vedere che in questo caso, se avessi, per esempio, un file AWK di grandi dimensioni e volessi aggiungere Yet Another " rule " ;, puoi prontamente andare in fondo al file, aggiungere regex e logica, ed essere fatto con esso. In particolare, per molte applicazioni, non ti preoccupi particolarmente di ciò che stanno facendo le altre regole e le regole non interagiscono realmente tra loro.

Pertanto, il file AWK diventa più simile a una "brodo di regole". Questa "zuppa di regole" la natura consente alle persone di concentrarsi molto strettamente sul proprio dominio con poca preoccupazione per tutte le altre regole che potrebbero essere nel sistema.

Ad esempio, Frank è interessato agli ordini per un totale di oltre $ 1000, quindi inserisce il sistema di regole che gli interessa. " SE order.total > 1000 ALLORA email Frank " ;.

Nel frattempo, Sally vuole tutti gli ordini dalla costa occidentale: " SE order.source == "WEST_COAST" ALLORA email Sally " ;.

Quindi, in questo banale caso inventato, puoi vedere che un ordine può soddisfare entrambe le regole, ma entrambe le regole sono indipendenti l'una dall'altra. Un ordine di $ 1200 dalla costa occidentale avvisa sia Frank che Sally. Quando Frank non è più preoccupato, eliminerà semplicemente la sua regola dalla zuppa.

Per molte situazioni, questa flessibilità può essere molto potente. Inoltre, come in questo caso, può essere esposto agli utenti finali per semplici regole. Usando espressioni di alto livello e forse script leggeri.

Ora, chiaramente, in un sistema complicato ci possono essere tutti i tipi di interrelazioni che possono accadere, ecco perché l'intero sistema non è "Fatto con le regole". Qualcuno, da qualche parte, si occuperà delle regole che non sfuggiranno di mano. Ma ciò non riduce necessariamente il valore che tale sistema può fornire.

Tenete presente che non vanno nemmeno a cose come i sistemi esperti, in cui le regole si basano sui dati che le regole possono creare, ma un sistema di regole più semplice.

Spero comunque che questo esempio mostri come un sistema di regole possa aiutare ad aumentare un'applicazione più grande.

Answer 4

Il più grande pro che ho visto per i motori delle regole è che consente ai proprietari di Business Rule di implementare le regole di business, invece di mettere a dura prova i programmatori. Anche se hai un processo agile in cui ricevi costantemente feedback dagli stakeholder e attraversi iterazioni rapide, non riuscirà comunque a raggiungere il livello di efficienza che può essere ottenuto facendo implementare anche le persone dalle regole aziendali.

Inoltre, non è possibile sottovalutare il valore nella rimozione del ciclo recompile-retest-redeploy che può derivare da una semplice modifica delle regole, se le regole sono incorporate nel codice. Spesso ci sono diversi team che sono coinvolti nel mettere la benedizione su una build e l'uso di un motore delle regole può rendere gran parte di ciò inutile.

Answer 5

Ho scritto un motore di regole per un client. La più grande vittoria è stata quella di includere tutte le parti interessate. Il motore potrebbe eseguire (o riprodurre) una query e spiegare cosa stava succedendo nel testo. Gli uomini d'affari possono guardare la descrizione del testo e sottolineare rapidamente le sfumature delle regole, delle eccezioni e di altri casi speciali. Una volta coinvolto il lato aziendale, la convalida è migliorata molto perché è stato facile ottenere il loro contributo. Inoltre, il motore delle regole può vivere separatamente dalle altre parti di una base di codice dell'applicazione in modo da poterlo utilizzare tra le applicazioni.

La contro è che ad alcuni programmatori non piace imparare troppo. I motori delle regole e le regole che metti in loro, insieme alle cose che li implementano, possono essere un po 'pelosi. Sebbene un buon sistema sia in grado di gestire facilmente trame logiche malate e contorte (o illogiche spesso;), non è così semplice come codificare un mucchio di istruzioni if (non importa quali siano alcuni dei motori di regole semplici fare). Il motore delle regole ti offre gli strumenti per gestire le relazioni tra regole, ma devi comunque essere in grado di immaginare tutto ciò nella tua mente. A volte è come vivere nel film Brasile . :)

Answer 6

(come tutto il resto) dipende dalla tua applicazione. Per alcune applicazioni (di solito quelle che non cambiano mai o le regole sono le migliori sulle costanti della vita reale, cioè non cambieranno sensibilmente in eoni, ad esempio proprietà fisiche e formule) non ha senso usare un motore di regole, semplicemente introduce ulteriore complessità e richiede allo sviluppatore di avere un set di competenze più ampio.

Per altre applicazioni è davvero una buona idea. Prendiamo ad esempio l'elaborazione degli ordini (gli ordini vanno dalla fatturazione all'elaborazione delle transazioni in valuta), di tanto in tanto c'è una piccola modifica a qualche legge o codice pertinente (in senso giudiziario) che richiede di soddisfare un nuovo requisito (ad esempio l'imposta sulle vendite , un classico). Piuttosto che cercare di forzare la tua vecchia applicazione in questa nuova situazione in cui all'improvviso devi pensare all'imposta sulle vendite, dove come prima non l'hai fatto, è più facile adattare il tuo set di regole piuttosto che immischiarti in potenzialmente un grande set di codice.

Quindi il prossimo emendamento del tuo governo locale richiede la segnalazione di tutte le vendite entro un certo criterio, piuttosto che devi entrare e aggiungere anche quello. Alla fine ti ritroverai con un codice molto complesso che si rivelerà piuttosto difficile da gestire quando ti giri e vuoi ripristinare l'effetto di una delle regole, senza influenzare tutte le altre ...

Answer 7

Finora tutti sono stati molto positivi riguardo ai motori delle regole, ma consiglio al lettore di diffidare. Quando un problema diventa un po 'più complicato, potresti improvvisamente scoprire che un intero motore di regole è stato reso inadatto o molto più complicato che in un linguaggio più potente. Inoltre, per molti problemi, i motori delle regole non saranno in grado di rilevare facilmente proprietà che riducono notevolmente il tempo di esecuzione e l'impronta di memoria della valutazione della condizione. Vi sono relativamente poche situazioni in cui preferirei un motore di regole a un framework di iniezione di dipendenza o un linguaggio di programmazione più dinamico.

Answer 8

" ma davvero, quante app hanno davvero tante modifiche? "

Onestamente, ogni app su cui ho lavorato ha subito un serio flusso di lavoro e / o cambiamenti logici dal concetto fino a ben dopo la distribuzione. È il motivo numero uno per la "manutenzione" programmazione ...

La realtà è che non puoi pensare a tutto in anticipo, quindi alla ragione dei processi Agili. Inoltre, i BA sembrano sempre perdere qualcosa di vitale fino a quando non si trova nei test.

I motori di regole ti costringono a separare veramente la logica aziendale dalla presentazione e dall'archiviazione. Inoltre, se si utilizza il motore giusto, i BA possono aggiungere e rimuovere la logica, se necessario. Come ha detto Chris Marasti-Georg, mette in discussione il BA. Ma oltre a ciò, consente al BA di ottenere esattamente ciò che sta chiedendo.

Answer 9

Un motore di regole è una vittoria su un'applicazione configurabile in cui non si desidera eseguire build personalizzate se può essere evitato. Sono anche bravi a centralizzare grandi basi di regole e algoritmi come Rete sono efficienti per una rapida corrispondenza con grandi set di regole.

Answer 10

Molte buone risposte già ma volevo aggiungere un paio di cose:

1. nell'automatizzare una decisione di qualsiasi complessità la cosa critica diventa rapidamente la tua capacità di gestire piuttosto che eseguire la logica in questione. Un motore di regole non ti aiuterà in questo: devi pensare alle capacità di gestione delle regole di un sistema di gestione delle regole di business. La maggior parte dei motori di regole commerciali e open source si è evoluta in sistemi di gestione delle regole con repository, reportistica sull'utilizzo delle regole, versioning ecc. Un repository di regole, strutturato in set di regole coerenti che possono essere orchestrati per prendere decisioni aziendali è molto più facile da gestire rispetto a migliaia di righe di codice o una minestra di regole.
2. Esistono molti modi per utilizzare un approccio dichiarativo e basato su regole. L'uso delle regole per gestire un'interfaccia utente o come parte della definizione di un processo può essere molto efficace. L'uso più prezioso di un approccio basato su regole, tuttavia, è quello di automatizzare le decisioni aziendali e fornirle come servizi decisionali vagamente accoppiati che accettano input, eseguono regole e restituiscono una risposta: una decisione. Cosa di questi come servizi che rispondono a domande per altri servizi come "questo cliente è un buon rischio di credito" o "quale sconto devo offrire a questo cliente per questo ordine o" qual è la migliore vendita incrociata per questo cliente in questo momento. Questi servizi decisionali possono essere realizzati in modo molto efficace utilizzando un sistema di gestione delle regole e consentono una facile integrazione dell'analisi nel tempo, qualcosa di cui beneficiano molte decisioni.

Answer 11

Vedo i motori di regole, processi e dati (database a.k.a.) essenzialmente simili. Ma, per qualche motivo, non diciamo mai che il blackbox del sottosistema persistenza è negativo.

In secondo luogo, dal mio POV, un modello anemico non è uno che è leggero nella implementazione dei comportamenti, è uno che è leggero nei comportamenti stessi . Il metodo effettivo che descrive un comportamento disponibile in un oggetto modello di dominio non deve essere eseguito dall'oggetto stesso.

Answer 12

La più grande complessità della mia esperienza in Rule Engines è che:

1. da OOP POV è una vera seccatura riformattare e testare le regole scritte in un linguaggio dichiarativo mentre si sta eseguendo il refactoring del codice che le influenza.
2. Spesso dovremmo sempre pensare all'ordine di esecuzione delle regole che si trasforma in un casino quando ce ne sono molte.
3. Alcune modifiche minori possono innescare comportamenti scorretti delle regole che portano a errori di produzione. In pratica non è sempre possibile coprire tutti i casi con test in anticipo.
4. Gli oggetti che mutano le regole usati in altri aumentano anche la complessità causando agli sviluppatori di suddividerli in fasi