Cosa significa in realtà "logica aziendale" se non "tutto il codice non di terze parti"?

Ho sentito persone parlare della logica aziendale molto al 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 affermazioni (parafrasate) che vedo spesso:

• "La logica di business è la parte del tuo programma che codifica le regole di business reali." La maggior parte delle definizioni che ho letto sono circolari come questa.

• "La logica di business è tutto unico per la tua particolare applicazione." Non vedo come questo sia diverso da "la tua particolare applicazione non è altro che una logica aziendale", a meno che non abbiamo reinventato accidentalmente un mucchio di ruote per le quali avremmo potuto usare software di terze parti. Da qui il titolo della domanda.

• "Dovrebbe esserci un livello di logica aziendale sopra il livello di accesso ai dati e sotto il livello della GUI." Nel codice che scrivo, gli accessi al database devono sapere a quali dati dovrebbero accedere e il codice dell'interfaccia utente deve sapere molto su ciò che viene visualizzato per visualizzarlo correttamente, e non c'è nulla da fare davvero tra quei due posti diversi dal passaggio di BLOB di dati tra client e server. Quindi, cosa dovrebbe effettivamente andare in un livello di logica aziendale?

• "La logica aziendale dovrebbe essere separata dalla logica di presentazione." La maggior parte delle richieste di funzionalità che riceviamo è di modificare la logica di presentazione per motivi di lavoro. Se una delle regole aziendali è quella di visualizzare i prezzi dei titoli di Stato statunitensi nella notazione 32 per impostazione predefinita (fornendo anche un'interfaccia utente per l'utente per configurarlo), la logica di presentazione deve almeno sapere che esiste questa regola, se non la implementa completamente. Inoltre, sembra che una parte importante della progettazione di UX stia aiutando l'utente a comprendere le regole aziendali che il nostro software sta cercando di implementare.

È possibile che io effettivamente faccia parte di un team che esegue solo la logica aziendale e che tutta la logica non aziendale viene eseguita da altri team? Oppure l'intero concetto di "logica di business" come entità separata può funzionare solo per determinate applicazioni o architetture?

Per rendere concrete le risposte: fai finta di dover reimplementare l'app Pizza di Domino. Qual è la logica aziendale e qual è la logica non aziendale dell'app? E come sarebbe possibile mettere quella logica aziendale che ordina la pizza nel suo "strato" di codice, senza che la maggior parte delle informazioni sulla pizza penetri nei livelli di accesso e presentazione dei dati?

Aggiornamento: sono giunto alla conclusione che probabilmente il mio team sta eseguendo il 90% di codice UI e la maggior parte - ma non tutto - di ciò che chiameresti logica aziendale proviene da altri team o aziende. Fondamentalmente, la nostra applicazione è per il monitoraggioi dati finanziari e quasi tutte le funzionalità sono modi in cui l'utente può personalizzare i dati che vede e come li vede. Non ci sono acquisti o vendite in corso (anche se ci integriamo un po 'con altre app della nostra azienda che lo fanno) e i dati effettivi vengono 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 gestiamo che probabilmente si qualificano come logica aziendale. In realtà esiste un'app mobile che attualmente parla con alcuni dei nostri codici di backend e so esattamente quale parte del nostro codice di frontend vorrei condividere con la nostra UI in un mondo ideale (fondamentalmente la M nel nostro quasi-MVC) quindi Immagino sia il BLL per noi.

Sto accettando la risposta di user61852 poiché mi ha dato una comprensione molto più concreta di ciò che la "logica aziendale" fa e non fa riferimento.

Ti darò alcuni consigli per quanto riguarda le applicazioni CRUD , dal momento che non ho molta esperienza nei giochi o nelle app graficamente intense:

• La logica aziendale di solito implica regole che il proprietario dell'azienda ha appreso o deciso negli anni di attività, come ad esempio: "rifiuta qualsiasi nuovo credito se il cliente non ha ancora finito di pagare l'ultimo" o "non vendiamo la colazione 11.00 " o " lunedì e martedì, i clienti possono acquistare due pizze al prezzo di una " .
• Naturalmente il livello di presentazione deve mostrare un messaggio che indica la disponibilità di uno sconto o la ragione del rifiuto di un credito, ma tale livello non sta decidendo queste cose, sta solo comunicando all'utente qualcosa che è accaduto sotto il cofano.
• La logica aziendale di solito comporta un flusso di lavoro , ad esempio: "questo articolo deve essere approvato entro 3 giorni lavorativi da un responsabile o mettere in una fase di" richiesta di informazioni ", se il cliente non ha inviato i documenti richiesti, l'articolo viene rifiutato" .
• Il livello di presentazione di solito non si occupa di quel tipo di flusso di lavoro, ma riflette solo gli stati del flusso di lavoro.
• Inoltre, il livello di accesso ai dati è in genere semplice, poiché le decisioni sono già state prese dalla logica aziendale. Questo livello è interessato quando si decide di migrare i dati da MS SQL Server a Oracle, ad esempio
• È vero a volte la GUI esegue alcune convalide per evitare le chiamate al server, ma è qualcosa che dovrebbe essere fatto in modo giudizioso o potresti avere molta logica aziendale in quel livello.
• Gran parte della tua confusione potrebbe derivare dal fatto che nella tua applicazione non vi è alcuna separazione di preoccupazioni ed effettivamente hai troppa logica aziendale nel livello di presentazione. Il fatto che tu abbia (erroneamente) una logica di business nel tuo livello di applicazione o livello di accesso ai dati non cambia il fatto che si tratti di una logica di business.
• Cose come visualizzare le distanze nel sistema metrico invece di miglia / iarde / piedi non sono logiche di presentazione, sono logiche aziendali . Il livello aziendale deve restituire i dati nelle unità richieste e indicare al livello di presentazione quali unità sta gestendo affinché mostri le etichette appropriate, ma è sicuramente un problema di logica aziendale.
• La logica aziendale non dovrebbe essere influenzata dal fatto che stai usando Oracle ora invece di Postgres, o dal fatto che la società abbia cambiato il logo o il foglio di stile.
• Esistono regole aziendali indipendentemente dal fatto che tu lo automatizzi o meno scrivendo un'app. Possono essere applicati anche quando l'azienda utilizza una soluzione a bassa tecnologia come carta e penna.
• Se disponi di una versione mobile dell'app desktop o di una versione Web , ognuna di queste versioni ha un livello di presentazione diverso , ma (si spera) lo stesso livello aziendale.

Sembra che la maggior parte del tuo lavoro possa essere nel livello dell'interfaccia utente. La modifica del formato di visualizzazione per motivi commerciali non implica alcuna logica aziendale. La modifica è una modifica alla logica della vista.

Essere in grado di cambiare il formato implica alcune logiche aziendali che potrebbero comportare la persistenza della preferenza.

Persistere il formato in un cookie, potrebbe anche essere implementato nel livello di visualizzazione.

Tuttavia, questo potrebbe essere implementato in modo MVC. (Alcuni modelli implementano la vista come proprio MVC in grado di gestire le preferenze.)

• Le preferenze dell'utente potrebbero essere memorizzate dal modello (database / cookie).
• Il controller reagirebbe alle richieste di formattazione modificando le preferenze dell'utente nel modello.
• La vista si adatterà alle preferenze dell'utente. La preferenza può essere richiesta dal modello o fornita dal controller.

Fare un'ipotesi plausibile sulla tua domanda.

• Esiste un modello contenente obbligazioni disponibili e dati sui prezzi per esse.
• C'è una vista che consente all'utente di vedere varie cose che possono fare: cercare obbligazioni, visualizzare i prezzi, confrontare i rendimenti, prendere gli ordini e che mostra i risultati restituiti dal modello di business in risposta alla richiesta.

• La logica aziendale gestisce cose come:

  • Esecuzione di una ricerca e visualizzazione della vista.
  • Trovare i prezzi per un'obbligazione e fornire la visualizzazione.
  • Confronto dei rendimenti e fornitura di dati per la visualizzazione da visualizzare.
  • Elaborazione degli ordini e archiviazione nel modello.

Se ciò viene fatto correttamente, dovrebbe essere possibile fornire più componenti di visualizzazione senza modificare il modello o la logica aziendale. Ad esempio, se il progetto attuale è un sito Web, un nuovo server di visualizzazione per un'applicazione iPhone o Android userebbe il modello e la logica aziendale esistenti. Questi possono introdurre nuove funzionalità aziendali per fornire notifiche push quando viene eseguito un ordine, che può richiedere modifiche a più livelli.

Questa suddivisione consente la separazione delle preoccupazioni.

• Il livello dati rappresentato dal modello tende ad essere relativamente stabile.
• Il livello aziendale è il punto in cui vengono applicate le decisioni aziendali: la richiesta / può essere soddisfatta? Sono stati ottenuti tutti i dati richiesti? L'utente è autorizzato? Ci sono delle bandiere rosse sulla transazione?
• Il livello di visualizzazione tende ad essere meno stabile e potrebbe essercene più di uno. È qui che risiede l'aspetto grafico dell'applicazione. È possibile ri-skin completamente un'applicazione, senza cambiare gli altri livelli.