In che modo l'utilizzo di un motore di regole influisce sulla progettazione, sull'implementazione e sulle prestazioni di un'applicazione?

La decisione di esporre un'interfaccia per il personale non tecnico per modificare le regole di business dipende in gran parte da diversi fattori, inclusi gli obiettivi del progetto, il costo del progetto, la durata del progetto e il rapporto tra sconosciute nel progetto.

Ad esempio, se credessi che nessuno userebbe l'interfaccia delle regole, probabilmente opterei per l'implementazione. Tuttavia, se avessi motivo di credere che i cambiamenti sarebbero frequenti e che i diversi utenti finali si aspetterebbero che esistano regole diverse, allora prenderei in considerazione la possibilità di lavorare su tali funzionalità.

Ho scelto di farlo su un progetto e ci sono voluti anni prima che la funzione fosse mai utilizzata in modo esteso. Sospettavo che alla fine avremmo avuto utenti finali che vorrebbero personalizzare le cose da sé, quindi abbiamo implementato questa funzionalità in pezzi.

È iniziato come qualcosa che solo alcune persone, come sviluppatori o amministratori, potrebbero utilizzare. L'interfaccia era goffa, ma utilizzabile se sapevi cosa stavi facendo. Ma quando il prodotto si stava avvicinando al completamento, la logica del backend del motore delle regole è stata utile e il nostro team di progettazione ha fornito un'interfaccia utente bella e orientata al cliente.

Se dovessi farlo diversamente, potrei scegliere una diversa architettura di database solo perché la curva di apprendimento è alta. In breve, la sua creazione ha portato presto a molte funzionalità rivolte ai clienti senza il mal di testa di dover tornare nel codice e refactoring per includere tutte le regole dinamiche.

Se dovessi farlo, creerei un linguaggio specifico per il dominio per esprimere le regole e forse dare ai tipi di biz un'interfaccia per modificarlo se richiesto. Quindi usa un linguaggio funzionale (come Haskell, Lisp o Erlang) per valutare le regole.

Se fosse richiesto un parallelismo massiccio, andrei con Erlang che fa molto bene la concorrenza. L'utilizzo di Erlang si adatta bene da 1 nodo a 100 o più.

Se si pensa alle regole come algebra che verranno applicate a un set di dati, diventa molto più semplice escludere ciò che è necessario nel codice e dimostrare a se stessi (o ai propri manager) che è corretto. Questo è uno di quei posti in cui un linguaggio funzionale funzionerà a tuo favore.

Ho scritto un'applicazione basata su WF (Windows Workflow Foundation). Il mio capo (un DBA) era convinto che WF potesse eseguire multi-threading senza la necessità di pianificare la concorrenza. La memoria è stata divisa a fondo, ma c'erano così tanti problemi che non riesco a spiegarlo in pochi paragrafi ed è solo un po 'correlato alla tua domanda ... quindi continuo.

Possibilità di iterare BL:
WF fa bene.
consente ai non tecnici di "creare un'app": WF lo fa bene SE l'architettura funziona E i nontechi capiscono i limiti tecnici ... I nostri no.
Capacità di comprendere le regole aziendali in generale:
Esistono alcuni componenti aggiuntivi che possono eseguire alcune operazioni di base, in modo molto simile a come sharepoint può automatizzare i flussi di lavoro. Non sono riuscito a entrare in questi articoli.
Qualità dei realizzatori di software:
Mediocre. La WF non ha funzionato bene per i nostri scopi, ma il sistema era mal progettato e le mie mani erano legate.
Velocità delle applicazioni:
Lento. La curva di apprendimento è abbastanza ripida sia per gli sviluppatori che per gli utenti finali. Il modo in cui WF ha separato la memoria (domini delle app Se ricordo) ha reso la comunicazione cross-thread, i mutex e altri concetti di threading kludgy o semplicemente non funzionano affatto.

In definitiva, ho scritto un prototipo per dimostrare che WF fallisce nel modo in cui è stato implementato. L'ho sostituito con multi-threading comune. Le prestazioni e la leggibilità del codice sono aumentate. Prendi questo con un pizzico di sale in quanto questa è stata la mia prima applicazione WF professionale.

Nontechs può arrivare a credere praticamente che tutto è possibile senza un programmatore richiesto, un negativo potenzialmente grande all'intero "dummy down" di BL; i problemi sociologici relativi a questo hanno ucciso il progetto.

Se potessi tornare indietro e farlo a modo mio : usa il threading tradizionale e lo stampaggio BL ottenuto tramite Decorator Pattern. Ho scritto una dimostrazione del concetto che utilizzava queste tecnologie e ha funzionato bene. E la mappatura BL deve essere racchiusa in un'interfaccia utente semplice.
Aggiornamento
Ho trovato un vecchio post che ho scritto quando si lavora con problemi di concorrenza. Il codice mostra come stampare "ciao mondo" in flussi di lavoro paralleli non funziona senza una comprensione di ciò che accade sotto le copertine (che sconfigge l'intero scopo dell'astrazione WF). Il moderatore MSDN spiega una panoramica di alto livello su come le attività parallele sono realmente sequenziali. Conclude fondamentalmente "è necessario leggere l'intero manuale" per fare qualcosa di fondamentale. link

Buona fortuna.

Ho avuto un'esperienza non perfetta collegandomi dal codice Java a un motore di regole Oracle. Alcuni di questi possono essere dovuti all'inesperienza da parte degli autori delle regole, ma questo è quello che ho affrontato.

• Abbiamo implementato il nostro motore di regole come dispositivo senza stato. Il chiamante doveva raccogliere tutti i parametri e passarli al motore per la valutazione. Ciò significava che se la regola richiedeva un altro campo di dati, tutti i client dovevano essere aggiornati, questo annullava il vantaggio di poter aggiornare le regole indipendentemente dai loro consumatori.
• Il motore ha pubblicato un WSDL SOAP, ma è stato generato automaticamente dal set di regole. Modifiche minori alle regole rompono il contratto con i consumatori.
• Il motore è stato bravo a valutare le regole, ma è stato terribile nel dirci perché la valutazione è fallita. È stato difficile alimentare i messaggi di errore informativi all'utente.
• Il WSDL non era adatto al consumo generale. Il set di regole più semplice aveva un WSDL di 14 pagine, che esponeva gli interni della base delle regole. Abbiamo dovuto inserire uno strato di traduzione SOA in primo piano per presentare una facciata di facile utilizzo. Quindi, invece di chiamare una libreria locale affidabile al 100%, c'erano due server extra nel ciclo. Ciò non aggiunge all'affidabilità in meno. Inoltre, qualsiasi modifica alla firma delle regole ha coinvolto tre team eterogenei che aggiornano il codice. Non è la mia definizione di agile!
• Ogni volta che il set di regole richiede aggiunte, il WSDL dovrebbe essere aggiornato, il che significa che i clienti non lo comprendono più. Ciò ha portato all'aggiunta di nuovi endpoint SOAP per v2, v3 .. che hanno avuto effetti a catena sull'avere bisogno di aggiornare le regole del firewall.
• Le regole erano espresse in "inglese strutturato" che era facilmente comprensibile per regole semplici, ma vicino all'opaco per regole complesse.
• Non siamo mai riusciti a trovare appaltatori che conoscessero il linguaggio di creazione delle regole.
• Il linguaggio delle regole non ha implementato matrici, ricorsione o orientamento agli oggetti. In un caso, l'unico modo per implementare una regola era tramite un callout a un foglio di calcolo di Excel, in cui la regola era implementata in VB. Perché preoccuparsi?

Non credo che la scelta di usare un motore di regole (o meno) sia chiara. Ti suggerisco di prototipare qualsiasi motore che intendi utilizzare, quindi prendere una decisione informata. Non sono certo un proiettile d'argento ...