Come progettare un sistema di convalida del motore di regole per essere asincrono e altamente performante!

Question

Come progettare un sistema di convalida del motore di regole per essere asincrono e altamente performante!

#1 da (3 voti)

0

Sto implementando un sistema di validazione che ha alcuni vincoli, ci sono una categoria di utenti diciamo 30 e per ogni categoria ci sono un certo numero di regole. In realtà ci sono 100 diverse regole.

Ho una multimap che mappa dato user_category_id alla lista di rule_id's.

Vincolo 1. La regola dovrebbe essere eseguita solo se è abilitata per quella categoria utente. Le regole sono configurate in modo diverso in base al relativo aggiornamento o inserimento.

Qui sto pensando di usare il modello di strategia per convalidare le regole.

Dal contesto passerò come parametro (user_category_id, rule_id's list e se è per Update o insert). Ogni regola, credo, dovrebbe essere una classe separata con metodi per ottenere il valore id della regola, eseguire il metodo per la determinata categoria utente e la logica in base al relativo aggiornamento o inserimento.

Quindi la classe di contesto avrà la multimap per user_category_Id su rule_id. e il valore per la convalida della regola per l'aggiornamento o l'inserimento.

Nell'interfaccia di IStrategy avrà la firma del metodo. Ma quale sarebbe il tipo di ritorno del metodo di cui non sono sicuro. Esiste una classe Response che incapsula la mia risposta e viene inviata all'utente.

L'ultima parte è come progettare la logica della regola. Ci sono centinaia di regole diverse. Come andare su questo compito? Dovrei incapsulare tutte le oltre 100 regole in classi separate? Sento che dovrei usare lo schema della strategia, ma non sono chiaro su come eseguire l'implementazione? Ho bisogno di una guida. Fammi sapere se sono necessarie ulteriori informazioni per il lavoro di progettazione di cui sopra. Qualsiasi suggerimento e guida per migliorare il design di cui sopra sarà molto apprezzato.

architecture design-patterns object-oriented-design rules-and-constraints strategy

posta John Doe 20.02.2017 - 18:40

fonte

1 risposta

Leggi altre domande sui tag architecture design-patterns object-oriented-design rules-and-constraints strategy

Perché dovrei rilasciare il mio codice sotto licenza BSD e perché no sotto LGPL? [chiuso] Aggiungi metodo all'interfaccia per una sola implementazione

score 3 · Accepted Answer

Questa risposta sarà incompleta in quanto non affronta la tua domanda su "come progettare" - se incapsulare classi o no.

Ma nell'interesse dell'efficienza, penso che tu possa separare le tue regole in gruppi in base alle loro dipendenze. Cioè:

Let A be a rule, and B be a rule, both applying to the same categories.

Abbiamo questi casi:

A has the same truth value of B (both either apply or don't apply)
A has the opposite value of B
A and B are not reliably dependent.

Se il caso 1 contiene, puoi inserire A e B insieme in un singolo "gruppo di regole" e testare solo una regola per ogni gruppo. La verità di questa regola è la verità del gruppo.

Se il caso 2 vale, allora puoi posizionare A e B in diversi gruppi collegati da una "meta-regola" che aggiorna la verità di un gruppo una volta che l'altro è noto. Un gruppo di gruppi collegati in questo modo è una famiglia .

Se il caso 3 vale, i due gruppi non sono collegati.

Un singolo gruppo è una famiglia a parte.

Ora invece di 100 regole potresti avere 90 gruppi e 80 famiglie e hai solo bisogno di 80 assegni. Se i controlli delle regole hanno un costo, per ogni famiglia esegui la regola più economica.

Famiglie indipendenti dalla costruzione, se vuoi puoi eseguire i controlli in parallelo.

( In realtà questa è una semplificazione - non sfrutta la conoscenza della probabilità congiunta delle regole e si occupa solo delle certezze. Ma per essere in grado di sfruttare una conoscenza meno che certa, le cose dovrebbero diventare molto più complicato )

Per ogni famiglia manterrai anche una statistica: quante volte è passato il controllo e quante volte il test è fallito e il controllo delle regole è stato interrotto da quella famiglia.

Quindi, si avvia il controllo in ordine decrescente di efficienza della famiglia - a partire dalla famiglia più efficiente, quella con il prodotto più basso di (passaggi / totale) ha moltiplicato il costo. A poco a poco, le regole si ordineranno per ottenere la massima efficienza. Le regole che passano sempre fluttuano verso il basso e vengono controllate per ultime (e potresti volerle controllare ed eventualmente disabilitarle del tutto).

( Ancora una volta applichiamo ciecamente questa struttura a tutti gli utenti senza sfruttare alcuna conoscenza su di essi (profilazione). In generale, le regole corrisponderanno a diversi "tipi" di utenti con probabilità diverse. le cose dovrebbero essere più complicate, una parte di questa complessità può essere tradotta in più regole senza complicare il framework )