Ho sentito parlare di business logic molto sul lavoro e online, e ho letto diverse domande su questo sito, ma il termine non ha ancora molto senso per me. Ad esempio, ecco alcune dichiarazioni (parafrasate) che vedo spesso:
-
"La logica aziendale è la parte del tuo programma che codifica le attuali regole aziendali." La maggior parte delle definizioni che ho letto sono di tipo circolare.
-
"La logica aziendale è tutto particolare per la tua particolare applicazione." Non vedo come questo sia diverso da "la tua particolare applicazione non è altro che la logica del business", a meno che non abbiamo reinventato casualmente un gruppo di ruote per cui avremmo potuto utilizzare il software di terze parti esistente. Da qui il titolo della domanda.
-
"Dovrebbe esserci un livello di business logic sopra il livello di accesso ai dati e sotto il livello della GUI." Nel codice che scrivo, gli accessor del database devono sapere a quali dati dovrebbero accedere, e il codice UI deve sapere molto su cosa sta visualizzando per visualizzarlo correttamente, e non c'è niente da fare nel mezzo questi due posti diversi dal passaggio di blocchi di dati tra client e server. Quindi cosa dovrebbe effettivamente entrare in un livello di business logic?
-
"La logica aziendale dovrebbe essere separata dalla logica di presentazione." La maggior parte delle richieste di funzionalità che otteniamo sono di modificare la logica di presentazione per motivi aziendali. Se una delle regole aziendali è quella di visualizzare i prezzi dei titoli di stato USA in notazione 32ss per impostazione predefinita (fornendo anche un'interfaccia utente per l'utente per configurarlo), la logica di presentazione deve almeno sapere che questa regola esiste, se non pienamente implementarla. Inoltre, sembra che una parte importante del design di UX aiuti l'utente a comprendere le regole aziendali che il nostro software sta cercando di implementare.
È possibile che io sia in realtà in una squadra che fa solo la logica aziendale e che tutte le altre logiche non fanno uso di altre logiche? Oppure l'intero concetto di "business logic" come entità separata è utilizzabile solo per determinate applicazioni o architetture?
Per aiutare a rendere concrete le risposte: fai finta di dover reimplementare l'app Domino's Pizza. Qual è la logica aziendale e qual è la logica non commerciale di tale app? E come sarebbe possibile mettere quella logica aziendale di ordine della pizza nel proprio "strato" di codice, senza che la maggior parte delle informazioni sulla pizza sanguinassero nei livelli di accesso ai dati e di presentazione?
Aggiornamento: sono giunto alla conclusione che il mio team sta probabilmente eseguendo il 90% di codice dell'interfaccia utente e la maggior parte, ma non tutte, di ciò che chiamereste logica aziendale proviene da altri team o aziende. Fondamentalmente, la nostra applicazione è per monitoraggio di dati finanziari, e quasi tutte le funzionalità sono modi per l'utente di personalizzare quali dati vedono e come li vedono. Non ci sono acquisti o vendite in corso (anche se integriamo un po 'con altre app della nostra azienda che lo fanno), e i dati effettivi sono forniti da un sacco di fonti esterne. Ma permettiamo agli utenti di fare cose come inviare copie dei loro "monitor" ad altri utenti, quindi i dettagli di come li gestiamo probabilmente si configurano come logica aziendale. In realtà c'è un'app mobile che attualmente parla di alcuni dei nostri codici back-end, e so esattamente quale parte del nostro codice di frontend mi piacerebbe che condividesse con la nostra UI in un mondo ideale (fondamentalmente la M nel nostro quasi-MVC) quindi Suppongo che sia la BLL per noi.
Accetto la risposta dell'utente61852 poiché mi ha fornito una comprensione molto più concreta di ciò che "logica aziendale" fa e non fa riferimento.