Che cosa definisce una regola aziendale, al contrario della logica di presentazione o applicazione?

Una regola aziendale è definita dagli uomini d'affari e si riferisce a questioni di business, indipendentemente dal modo in cui queste regole sono implementate.

Esempi non ambigui:

• La modifica del conto bancario di un beneficiario deve essere approvata da un contabile diverso da quello che ha registrato il cambiamento (principio dei quattro occhi).
• Un agente di acquisto può emettere un ordine di acquisto fino a $ 100.000. Oltre questo limite è richiesta l'approvazione di un manager.

Queste regole possono essere applicate puramente con mezzi organizzativi (una procedura formale che i dipendenti hanno dato a seguire) o attraverso l'automazione (nel sistema).

Esempio ambiguo:

• Il titolo del rapporto deve essere inferiore a 140 caratteri
• La descrizione del prodotto non deve essere più lunga di 2000 caratteri

Questi due esempi potrebbero essere:

• specifiche tecniche di lunghezza arbitraria, non giustificate da una regola aziendale, ma solo perché si presume che siano sufficienti;
• vere regole di business, se gli uomini d'affari decidessero che le informazioni non dovessero superare questi limiti in nessuna circostanza a causa di motivi di lavoro, ad esempio per garantire risposte concise ed elaborazione efficiente (ed evitare che i commessi debbano leggere romanzi lunghi invece di brevi istruzioni).

Per determinare se si tratta di una regola aziendale, il criterio più semplice sarebbe quello di chiedere se questa regola avrebbe senso senza il sistema (ad esempio, se le informazioni sarebbero processi tramite moduli cartacei). Nel tuo esempio chiaramente non lo è.

Una regola aziendale è in genere implementata nel livello della business logic, a causa della sua natura generale (indipendente dall'applicazione).

Ci sono un sacco di aree grigie e sovrapposizioni tra regole di business e logica applicativa, ma per essere una regola aziendale, un requisito dovrebbe essere un requisito che crea valore per l'azienda.

Dato l'esempio di inviare un messaggio e doverlo dividere in due a causa dell'API, il vero requisito aziendale è probabilmente che l'app deve essere in grado di inviare un messaggio di lunghezza arbitraria. Il proprietario dell'app potrebbe perdere denaro se gli utenti non fossero in grado di inviare messaggi più lunghi. La suddivisione del messaggio in più parti sarebbe l'implementazione di tale regola aziendale.

Questo non dovrebbe essere una regola di bussiness.

Le regole aziendali dovrebbero essere raccolte e idealmente indicate nel codice sorgente.

Dovrebbero descrivere la logica in relazione a tutti gli aspetti aziendali: dopo aver stampato una fattura, il numero della fattura non può più essere modificato e deve essere inserito nel registro di controllo.

Ora si può avere una regola aziendale: inviare una notifica su questo ... evento. Il codice di implementazione può fare riferimento a questa regola aziendale e indicare che, se necessario, divide un messaggio troppo grande in due parti inviate separatamente. Ciò non sembra un requisito in anticipo, ma una documentazione di implementazione in seguito. Un po 'come "si può fare clic su i per ricevere l'aiuto contestuale online."

Se uno ha solo regole di business, bene, aggiungi i dettagli di implementazione. Altrimenti, tenerli separati, mantenere la proprietà delle regole aziendali neutrali e senza troppa roba: gli uomini d'affari non dovrebbero sentirsi eccessivamente condizionati da dettagli imposti / "correzioni". È come l'impaginazione di liste e così via. "I risultati devono venire in pagine limitate, anche se deve essere selezionabile anche un'intera lista scorrevole". Cioè - come hai detto tu - qualcosa per la progettazione delle applicazioni. E - in contrasto con le regole di business decisive - racconta qualcosa sugli interna.

Avere due messaggi deve essere spiegato. Ma lasciatemi fare un paragone:

Un architetto dice: per un edificio per N persone e piani M ci sono ascensori K. Il proprietario dell'edificio vorrà avere le documentazioni tecniche: in che modo gli ascensori intelligenti attendono il primo e l'ultimo piano, quale strategia rispondere a un pulsante e così via. Dettagli importanti sull'implementazione tecnica , decisioni di progettazione intelligenti. L'invio di due messaggi di notifica rientra nella stessa categoria.

Nella regola aziendale "il messaggio di notifica" deve essere modificato in "notifica come uno o due messaggi (nota a piedi: se la notifica diventa troppo lunga)" ma giustificazione tecnica e dettagli dovrebbero andare altrove.

Ora l'implementazione può essere modificata senza che le regole aziendali vengano eseguite molto (quelle regole riguarderanno una "notifica", non un singolo "messaggio" parziale).