Quando è consigliabile NON utilizzare un Motore di Regole?[chiuso]

Question

Ho una abbastanza decente elenco dei vantaggi dell'utilizzo di un Motore di Regole, così come alcuni motivi per utilizzare il loro, quello di cui ho bisogno è un elenco di motivi per cui si dovrebbe utilizzare un Motore di Regole

Il migliore che ho finora è questo:

I motori delle regole non sono davvero destinato a gestire il flusso di lavoro o di processo esecuzioni né sono motori di workflow di processo o di strumenti di gestione progettato per fare le regole.

Eventuali altri grandi motivi perché si dovrebbe utilizzare?

Answer 1

Ottengo molto nervoso quando vedo persone che usano molto grandi set di regole (ad esempio, dell'ordine di migliaia di norme in un unico set di regole). Questo accade spesso quando il motore delle regole è un Singleton seduto al centro dell'impresa, nella speranza che il mantenimento di regole DRY li renderà accessibili a molte applicazioni che li richiedono. Vorrei sfidare chiunque a dirmi che un motore di regole di Rete con che molte regole è ben capito. Io non sono a conoscenza di strumenti in grado di controllare che non esistono conflitti.

Credo che il partizionamento regole imposta per tenerli piccolo è una scelta migliore. Aspetti possono essere un modo per condividere una regola comune incastonato tra molti oggetti.

Io preferisco un approccio più semplice, più dati guidati, ove possibile.

Answer 2

Vi darò 2 esempi tratti dalla esperienza personale in cui utilizzano un motore di regole era una cattiva idea, forse che vi aiuterà: -

1. In un progetto passato, ho notato che i file di regole (il progetto ha utilizzato Drools) conteneva un sacco di codice Java, tra cui i cicli, le funzioni ecc Essi erano essenzialmente file java mascherati da file di regole. Quando ho chiesto l'architetto sul suo ragionamento per la progettazione mi è stato detto che il "Regolamento non sono mai stati destinati ad essere gestito da utenti business".

Lezione :. Si chiamano "regole di business" per un motivo, non utilizzare le regole quando non è possibile progettare un sistema che può essere facilmente mantenuta / comprensibile dagli utenti commerciali

2. Un altro caso; Il progetto regole utilizzato perché i requisiti sono stati mal definiti / compresi e cambiati spesso. La soluzione del team di sviluppo è stato quello di utilizzare le regole ampiamente per evitare implementa codice frequenti.

Lezione : Requisiti tendono a cambiare molto durante i cambiamenti di rilascio iniziali e non giustificano l'utilizzo di regole. Utilizzare le regole quando il vostro business cambia spesso (non richieste). Ad esempio: - Un software che fa le tasse cambierà ogni anno come legislazioni fiscali cambiano e l'utilizzo di regole è un'ottima idea. Release 1.0 di una web app cambierà spesso gli utenti a identificare nuove esigenze, ma si stabilizzeranno nel corso del tempo. Non utilizzare le regole di come alternativa al codice di deploy.

Answer 3

Io sono un grande fan di Regole di Business dei Motori, in quanto può aiutare a rendere la vostra vita molto più facile, come un programmatore.Una delle prime esperienze che ho avuto mentre si lavora su un progetto di Data Warehouse era quello di trovare la Stored Procedure contenenti complicato CASO di strutture che si estende per oltre intere pagine.E ' stato un incubo per il debug, poiché è stato molto difficile capire la logica applicata in CASO lungo le strutture, e per determinare se si dispone di una sovrapposizione tra una regola a pagina 1 del codice e l'altro da pagina 5.Nel complesso, abbiamo avuto più di 300 tali norme contenute nel codice.

Quando abbiamo ricevuto un nuovo sviluppo del requisito, per qualcosa che si chiama Contabili di Destinazione, che coinvolgono il trattamento di più di 3000 regole, sapevo che qualcosa doveva cambiare.Allora sto lavorando su un prototipo che poi diventano il padre di quello che ora è un Custom motore regole di Business, in grado di gestire tutti i componenti di SQL standard di operatori.Inizialmente abbiamo iniziato a utilizzare Excel come strumento di creazione e , in seguito, abbiamo creato un ASP.net applicazione che permette agli Utenti di definire le proprie regole di business, senza la necessità di scrivere codice.Ora il sistema funziona bene, con pochissimi bug, e contiene oltre 7000 le regole per il calcolo di tale Contabilità di Destinazione.Non credo che uno scenario del genere sarebbe stata possibile solo hard-codifica.E gli utenti sono abbastanza felice che siano in grado di definire le proprie regole, senza di ESSA, diventando il loro collo di bottiglia.

Ancora, ci sono dei limiti a tale approccio:

• È necessario disporre in grado gli utenti business che hanno un'ottima comprensione del business di un'azienda.
• C'è un notevole carico di lavoro sulla ricerca tutto il sistema (in il nostro caso di un Data Warehouse), al fine di determinare tutti gli hard-coded condizioni, che senso di tradurre in regole per essere gestite da un Motore regole di Business.Abbiamo anche dovuto prendere la buona cura che questi modelli iniziali per essere comprensibile dagli Utenti di Business.
• È necessario disporre di un'applicazione utilizzata per le regole di creazione, in cui algoritmi per il rilevamento della sovrapposizione di regole di business è implementato.Altrimenti vi ritroverete con una grande confusione, dove non si capisce più i risultati che ottengono.Quando si dispone di un errore di un generico componente come un Custom Motore regole di Business, può essere molto difficile per il debug e per coinvolgere un'ampia serie di test per assicurarsi che le cose che funzionavano anche prima di lavorare ora.

Ulteriori dettagli su questo argomento si possono trovare su un post ho scritto: http://dwhbp.com/post/2011/10/30/Implementing-a-Business-Rule-Engine.aspx

Nel complesso, il più grande vantaggio di utilizzare una Regola di Business dei Motori è che esso consente agli utenti di riprendere il controllo sulle regole di Business di definizioni e di creazione, senza la necessità di andare al reparto IT ogni volta che hanno bisogno di modificare qualcosa.Inoltre, la riduzione del carico di lavoro su di ESSO, un team di sviluppo, che ora possono concentrarsi sulla costruzione di roba con più valore aggiunto.

Ciao

Nicolae

Answer 4

Quello poit ho notato di essere "la spada a doppio taglio" è:

  

ponendo la logica nelle mani del personale non tecnico

Ho visto questo grande lavoro, quando si dispone di uno o due geni multidisciplinari sul lato non tecnico, ma ho anche visto la mancanza di tecnicità che porta a gonfiare, più bug, e in generale 4x sviluppo / manutenzione costi.

Quindi è necessario prendere in seria considerazione la vostra base di utenti.

Answer 5

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

Non è completo, ma ha alcuni buoni punti.

Answer 6

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

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

Un'altra opzione è se si dispone di un insieme lineare di regole che si applicano una sola volta in qualsiasi ordine per ottenere un risultato è quello di creare un'interfaccia groove e hanno gli sviluppatori a scrivere e distribuire queste nuove regole. Il vantaggio è che è perfidamente veloce perché normalmente si dovrebbe passare la sessione di sospensione o sessione di JDBC, così come i parametri in modo da avere accesso a tutti i dati, ma applicazioni in modo efficiente. Con una lista, infatti, non ci può essere un sacco di looping / corrispondenza che davvero in grado di rallentare il sistema ..... E 'un altro modo per evitare un motore di regole e di essere in grado di essere implementato in modo dinamico (sì, le nostre regole groove sono stati schierati in un banca dati e non abbiamo avuto ricorsione .... neanche incontrato la regola o non ha fatto). E 'solo un'altra opzione ..... oh e un ulteriore beneficio non è l'apprendimento della sintassi regole per gli sviluppatori in arrivo. Devono imparare un po 'di groove ma che è molto vicino a Java in modo che la curva di apprendimento è molto meglio.

In realtà dipende il vostro contesto. motore di regole hanno il loro posto e quanto sopra è solo un'altra opzione se si dispone di norme in materia di un progetto che si può decidere di distribuire in modo dinamico per situazioni molto semplificate che non richiedono un motore di regole.

fondamentalmente non usare un motore di regole, se si dispone di un semplice set di regole e può avere un interfaccia di groove invece ..... proprio come gli sviluppatori in modo dinamico schierabili e nuove parte della vostra squadra può imparare più velocemente di quanto la lingua sbava. (Ma questo è mio parere)

Answer 7

Nella mia esperienza, motori di regole funzionano meglio quando le seguenti condizioni:

1. dottrina ben definiti per il dominio del problema
2. di alta qualità (preferibilmente automatizzato) i dati per aiutare a guidare la maggior parte dei vostri input
3. L'accesso a esperti in materia
4. Gli sviluppatori di software con i sistemi di esperienza nella creazione di esperti

Se uno qualsiasi di questi quattro tratti mancano, è ancora potrebbe trovare un motore di regole funziona per voi, ma ogni volta che ho provato anche con 1 mancante, ho incontrato problemi.

Answer 8

Questo è certamente un buon inizio. L'altra cosa con motori di regole è che alcune cose sono ben capito, deterministica, e diretto. Payroll ritenuta è (o utilizzare per essere) così. potrebbero esprimerla come regole che sarebbero risolti da un motore di regole, ma si potrebbe esprimere le stesse regole abbastanza semplice tabella di valori.

Quindi, motori di workflow sono buoni quando si sta esprimendo un processo a lungo termine che avrà dati persistenti. motori di regole può fare una cosa simile, ma è necessario fare un sacco di complessità.

motori regole sono buoni quando si è complicato basi di conoscenza e hanno bisogno di ricerca. motori di regole in grado di risolvere problemi complessi, e possono essere adattati rapidamente alle mutevoli situazioni, ma impongono un sacco di complessità in merito all'attuazione di base.

Molti algoritmi decisionali sono abbastanza semplici per esprimere come un semplice programma di tavolo-driven senza la complessità implicita da un vero e proprio motore di regole.

Answer 9

Che vi consiglio vivamente le regole di business motori come Drools come open sorgente o Regole commerciale del motore come LiveRules

• Quando si ha un sacco di politiche aziendali che sono volatili in natura, è molto difficile mantenere quella parte del codice di tecnologia di base.
• Il motore di regole fornisce una grande flessibilità del quadro e facile da cambiare e distribuire.
• motori di regole non devono essere utilizzati in tutto il mondo, ma devono utilizzare quando si hanno molte politiche in cui i cambiamenti sono inevitabili su base regolare.

Answer 10

Io non capisco alcuni punti quali:
a) uomini d'affari ha bisogno di capire business molto bene, o;
b) il disaccordo su uomini d'affari non hanno bisogno di conoscere la regola.

Per me, come un popolo semplicemente toccando BRE, il beneficio della BRE è così chiamato a lasciare il sistema di adattarsi ai cambiamenti del business, da cui è focalizzata sulla adattativa del cambiamento.
Che importa se la regola fino al tempo x è diverso dalla norma impostare al momento y a causa di:
a) gli uomini d'affari non capiscono affari, o;
b) gli uomini d'affari non capiscono le regole?