Rappresenta le regole aziendali con le eccezioni

Se intendi rappresentare singoli controlli delle regole aziendali con eccezioni, non penso che sia una buona idea. Molte volte devi segnalare più di una condizione fallita e non fermarti sulla prima.

D'altra parte, ritengo che il controllo delle tutte le regole e quindi l'eliminazione di un'eccezione con il riepilogo sia una buona pratica.

Nell'esempio che ci hai fornito, ritengo che sollevare un'eccezione sia una cattiva idea. Se sai che l'utente non è autorizzato prima di iniziare a lavorare e permetti comunque loro di svolgere qualche funzione e poi schiaffeggiarli con un messaggio DOPO che hanno già completato l'attività, si tratta solo di una cattiva progettazione.

L'utilizzo di eccezioni per applicare le regole aziendali non è un buon progetto.

Non vedo quale sia il valore che genera un'eccezione nella creazione di una buona logica di business. Esistono dozzine di approcci per la gestione della logica aziendale che non implicano l'utilizzo di un sistema destinato a risolvere condizioni impreviste nel funzionamento di un sistema.

È previsto che nella logica aziendale, le condizioni non saranno soddisfatte; questo è il motivo per averlo in primo luogo, e non si vuole fare il doppio sullo stesso meccanismo che gestisce errori di I / O imprevisti, errori di memoria esauriti e riferimenti null. Questi sono guasti del sistema, ma rilevare le condizioni aziendali non soddisfatte è il buon funzionamento del sistema.

Inoltre, è un sistema maturo per conseguenze indesiderate. Poiché a un certo punto deve essere rilevata un'eccezione, si corre il rischio che una nuova regola aziendale venga enfatizzata da qualche parte che non è destinata o si ha la possibilità che il codice cerchi le regole aziendali rilevando eccezioni che non sono in realtà significate per questo. Sì, queste condizioni possono essere spiegate con buone pratiche di codifica, ma in qualsiasi sistema non banale su cui sta lavorando più di uno sviluppatore, gli errori accadranno, e devi solo sperare che non saranno costosi errori.

esprimere le regole aziendali è una cosa, implementarle è un'altra

pensa all'esperienza utente; se l'utente non è un venditore, perché dare loro un pulsante che dice 'creare fattura' affatto ?

Dipende interamente da ciò che viene fatto.

Innanzitutto, qual è il comportamento effettivo che desideri? Se qualcuno inserisce le proprie informazioni, allora un rifiuto e una finestra di dialogo che dice, in sostanza, "Non puoi farlo" è probabilmente corretto. Se si tratta di una persona di inserimento dati, che lavora da una pila di moduli, una finestra di dialogo è probabilmente anche buona, e la persona di inserimento dati può inserire i moduli non validi in una pila speciale. Se stai eseguendo l'elaborazione in batch, non vuoi fermarti, ma contrassegnalo e passa a quello successivo.

Una volta che hai il comportamento, devi decidere come implementarlo. Avere un controllo delle regole di business che genera un'eccezione è probabilmente una buona idea. Restituire un codice di ritorno e averlo trasmesso è un'altra cosa che può andare storta, e certamente non vuoi che le voci errate si aggravino.

Non preoccuparti delle spese di performance. Nel caso di un individuo che immette dati, è banale rispetto alle altre volte coinvolte. In genere, l'umano impiegherà più tempo in quel sistema. Nel caso di un lavoro batch, se le eccezioni sono un problema di prestazioni, si inseriscono troppi record errati e nella gestione della realtà e il reinserimento di tutti questi sarà più un problema delle eccezioni.

Avere un'eccezione solida e ben progettata che sia coerente è molto appropriata. Anche l'utilizzo di questo per applicare le regole aziendali può essere appropriato. In effetti, secondo la mia esperienza, più è complicata la regola degli affari, più è probabile che finirà per essere gestita in questo modo. Spesso è altrettanto semplice se non è più semplice scrivere un sistema dove sono previste eccezioni piuttosto che scrivere una logica di branching autorevole.

Ciò significa che le regole semplici che possono essere descritte in una singola frase in generale dovrebbero essere implementate in modo preventivo o autorevole a seconda di quale sia. Tuttavia, se si dispone di una regola che è multidimensionale e richiede più di tre o quattro fattori (soprattutto se la selezione di questi fattori è basata su uno o più degli altri fattori), la codifica delle eccezioni potrebbe essere più gestibile. Spesso in questi casi il percorso logico avrà molte eccezioni precursore che devono essere lanciate, (controlla perché l'azione non può essere eseguita) quindi (o viceversa) c'è una caduta nella sicurezza (per controllare che l'azione sia autorizzata) ), a volte ci sarà qualche logica di accumulo autorevole che deve essere controllata (la disponibilità discendente / antenato, gli stati precursori in cui gli oggetti devono essere inseriti, ecc.) quindi la logica cadrà nel processo attuale che può includere l'autorevolezza più diretta verifiche logiche direttamente pertinenti al processo.

Un vantaggio derivante da questo tipo di lancio di eccezioni è che consente di separare e riutilizzare le eccezioni dei precursori in più aree del progetto. (Questa è l'essenza di Aspect Oriented Programming.) In questo modo si incapsula un aspetto particolare delle regole aziendali generali in un componente autonomo e gestibile. In generale queste componenti corrisponderanno a 1-1 con i messaggi di errore lanciati. (Anche se a volte hai un componente che genera diverse eccezioni, non dovresti quasi mai avere la stessa eccezione generata da più componenti.)

Secondo me è più difficile progettare sistemi basati su eccezioni e il tempo di sviluppo iniziale è più lungo poiché devi costruire il processo di eccezione su tutti i livelli N. Tuttavia, questi sistemi generalmente finiscono per essere molto più stabili. Anche se non è mai possibile progettare un sistema che "non fallirà", il vantaggio del design basato su eccezioni è che si anticipa sempre il fallimento. Per la maggior parte delle persone il processo può essere contro-intuitivo. È come chiedere indicazioni e avere qualcuno che ti dice tutte le strade che non dovresti accendere.