In che modo l'uso di un motore di regole influisce sulla progettazione, l'implementazione e le prestazioni di un'applicazione?

Sono interessato alla capacità dei motori delle regole di:

• lancio e iterazione sulla logica aziendale
• fare in modo che gli "utenti aziendali" eseguano la modifica effettiva di tali regole anziché degli sviluppatori
• comprendere le regole aziendali in generale

Inoltre, l'utilizzo di un motore di regole influisce sulla qualità di un'applicazione?

L'uso di un motore di regole cambia se si stava eseguendo la distribuzione in un'installazione a 1 macchina rispetto all'architettura rispetto a un'architettura distribuita basata su cloud a più livelli che utilizza migliaia di macchine? Come sarebbe diverso?

La decisione se esporre un'interfaccia per il personale non tecnico per modificare le regole aziendali dipende in gran parte da diversi fattori, tra cui gli obiettivi del progetto, il costo del progetto, la durata del progetto e il rapporto tra noti e sconosciuti nel progetto.

Ad esempio, se credessi che nessuno avrebbe usato l'interfaccia delle regole, probabilmente avrei rinunciato a implementarlo. Tuttavia, se avessi motivo di credere che i cambiamenti sarebbero frequenti e che diversi utenti finali si aspetterebbero che siano in vigore regole diverse, prenderei in considerazione l'idea di lavorare sulla creazione di tale funzionalità.

Ho scelto di farlo su un progetto e ci sono voluti anni prima che la funzione fosse mai ampiamente utilizzata. Sospettavo che alla fine avremmo avuto utenti finali che avrebbero voluto personalizzare le cose da soli, quindi abbiamo implementato questa funzionalità a pezzi.

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

Se dovessi farlo diversamente, potrei scegliere un'architettura di database diversa solo perché la curva di apprendimento è alta. Ma in breve, la sua creazione iniziale ha portato in seguito a molte funzioni rivolte ai clienti in seguito senza il mal di testa di dover tornare indietro nel codice e riformattarlo per includere tutte le regole dinamiche.

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

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

Se pensi alle regole come a un'Algebra che verrà applicata a un set di dati diventa molto più facile capire cosa è necessario nel tuo codice e dimostrare a te stesso (o ai tuoi 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 il multi-threading senza la necessità di pianificare la concorrenza. La memoria è stata completamente divisa, ma c'erano così tanti problemi che non posso spiegarlo in pochi paragrafi ed è solo leggermente correlato alla tua domanda ... quindi continuo.

Capacità di iterare BL:
WF lo fa bene.
consentire ai non tecnici di "costruire un'app":
WF fa bene SE l'architettura funziona E i non tecnici comprendono i limiti tecnici ... I nostri no.
Capacità di comprendere le regole di business in generale:
ci sono alcuni componenti aggiuntivi che possono fare alcune cose di base, proprio come sharepoint può automatizzare i flussi di lavoro. Non sono entrato in questi articoli.
Qualità dei rilasci software:
mediocre. 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 è piuttosto ripida sia per gli sviluppatori che per gli utenti finali. Il modo in cui WF ha separato la memoria (domini app se ricordo) ha fatto in modo che la comunicazione cross-thread, i mutex e altri concetti di thread fossero complicati o semplicemente non funzionassero affatto.

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

Nontechs può arrivare a credere che praticamente tutto sia possibile senza che sia necessario un programmatore, un potenziale potenzialmente negativo per l'intero "manichino" di BL; problemi sociologici legati a questo hanno ucciso il progetto.

Se potessi tornare indietro e farlo a modo mio : usa la filettatura tradizionale e la modanatura BL ottenute tramite Decorator Pattern. Ho scritto una prova del concetto che ha usato queste tecnologie e ha funzionato bene. E la mappatura BL dovrebbe essere racchiusa in un'interfaccia utente semplice.
Aggiornamento
Ho trovato un vecchio post che ho scritto lavorando su problemi di concorrenza. Il codice mostra come la stampa di "ciao mondo" in flussi di lavoro paralleli non funziona senza una comprensione di ciò che accade sotto le copertine (che vanifica l'intero scopo dell'astrazione WF). Il moderatore MSDN spiega una panoramica di alto livello su come le attività parallele siano realmente sequenziali. Conclude fondamentalmente "devi leggere l'intero manuale" per fare qualcosa di così semplice. http://social.msdn.microsoft.com/Forums/en/windowsworkflowfoundation/thread/8a1fa165-ad5c-4cd2-b489-7ea5fc31fed8

In bocca al lupo.

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

• Abbiamo implementato il nostro motore delle 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 necessitava di un altro campo dati, tutti i client dovevano essere aggiornati, ciò negava il vantaggio propagandato di poter aggiornare le regole indipendentemente dai propri consumatori.
• Il motore ha pubblicato un WSDL SOAP, ma è stato generato automaticamente dal set di regole. Piccole modifiche alle regole violerebbero il contratto con i consumatori.
• Il motore è stato bravo a valutare le regole, ma terribile nel dirci perché la valutazione non è riuscita. È stato difficile inviare all'utente messaggi di errore informativi.
• 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 rule base. Abbiamo dovuto mettere uno strato di traduzione SOA di fronte per presentare una facciata adatta alle imprese. Quindi, invece di chiamare una libreria locale affidabile al 100%, c'erano due server extra nel loop. Ciò non aumenta l'affidabilità. Inoltre, qualsiasi modifica alla firma della regola ha coinvolto tre team diversi che aggiornano il codice. Non è la mia definizione di agile!
• Ogni volta che il set di regole richiedeva aggiunte, il WSDL doveva essere aggiornato, il che significava che i client non lo capivano più. Ciò ha portato all'aggiunta di nuovi endpoint SOAP per v2, v3 .. che hanno avuto effetti a catena sulla necessità di aggiornare le regole del firewall.
• Le regole erano espresse in "inglese strutturato" che era facilmente comprensibile per regole semplici, ma quasi opaco per regole complesse.
• Non siamo mai riusciti a trovare appaltatori che conoscessero il linguaggio di creazione delle regole.
• Il linguaggio delle regole non implementava matrici, ricorsione o orientamento degli oggetti. In un caso, l'unico modo per implementare una regola era tramite un callout a un foglio di calcolo Excel, in cui la regola era implementata in VB. Perché preoccuparsi?

Non penso 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 certamente un proiettile d'argento ...