Che cosa significa in realtà "business logic" se non "tutto il codice non di terze parti"?

22

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.

    
posta Ixrec 03.01.2015 - 00:05
fonte

2 risposte

25

Ti fornirò alcuni suggerimenti relativi alle applicazioni CRUD , poiché non ho molta esperienza in giochi o app ad alta intensità grafica:

  • La logica aziendale di solito comporta regole apprese dal proprietario dell'azienda o decise in anni di funzionamento, ad esempio: "rifiuta qualsiasi nuovo credito se il cliente non ha ancora finito di pagare l'ultimo ", o " non vendiamo la colazione dopo le 11:00 ", o " lunedì e martedì, i clienti possono acquistare due pizze al prezzo di uno " .
  • Naturalmente il livello di presentazione deve mostrare un messaggio che indica la disponibilità di uno sconto, o il motivo del rifiuto di un credito, ma tale livello non sta decidendo quelle cose, è solo comunicando all'utente qualcosa che è accaduto sotto il cofano.
  • La logica aziendale di solito implica un flusso di lavoro , ad esempio: "questo articolo deve essere approvato entro 3 giorni lavorativi da qualche manager o inserito in una fase di richiesta di informazioni, se il cliente non ha inviato i documenti richiesti, quindi l'elemento viene rifiutato ".
  • Il livello di presentazione di solito non si occupa di quel tipo di flusso di lavoro, 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 è influenzato quando si decide di migrare i dati da MS SQL Server a Oracle, ad esempio
  • È vero che a volte la GUI ha qualche convalida per evitare le chiamate al server, ma è qualcosa che dovrebbe essere fatto in modo giudizioso o potresti avere un sacco di logica di business in quel livello.
  • Gran parte della tua confusione potrebbe derivare dal fatto che nella tua applicazione non c'è separazione di preoccupazioni e in effetti hai troppa logica di business nel livello di presentazione. Il fatto che tu (erroneamente) abbia una logica di business nel tuo livello di applicazione o nel livello di accesso ai dati non cambia il fatto che si tratta di una logica aziendale di qualsiasi tipo.
  • Cose come la visualizzazione di distanze nel sistema metrico invece di miglia / iarde / piedi non è logica di presentazione, è logica aziendale . Il livello aziendale deve restituire i dati nelle unità richieste e indicare al livello di presentazione quali unità sta gestendo per mostrare le etichette appropriate, ma è sicuramente un problema di logica aziendale.
  • La logica aziendale non dovrebbe essere influenzata da il fatto che stai utilizzando Oracle ora invece di Postgres, o dal fatto che l'azienda abbia modificato il suo logo o foglio di stile.
  • Le regole aziendali esistono indipendentemente dal fatto che tu lo automatizzi scrivendo un'app. Possono essere applicati anche quando l'azienda utilizza una soluzione a bassa tecnologia come carta e penna.
  • Se hai una versione mobile dell'app desktop o una versione web , ognuna di quelle versioni ha un livello di presentazione diverso , ma (si spera) lo stesso livello aziendale.
risposta data 03.01.2015 - 02:08
fonte
4

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

Essere in grado di cambiare il formato implica alcune logiche di business che potrebbero comportare la persistenza delle preferenze.

Persistendo il formato su un cookie, potrebbe essere implementato anche nel livello vista.

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

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

Fai un'ipotesi plausibile sulla tua applicazione.

  • Esiste un modello contenente le obbligazioni disponibili e i relativi dati di prezzo.
  • C'è una vista che consente all'utente di vedere varie cose che possono fare: cercare obbligazioni, visualizzare i prezzi, confrontare i rendimenti, prendere ordini e visualizzare 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 da visualizzare.
    • Individuazione dei prezzi per un'obbligazione e fornitura della vista da visualizzare.
    • Confronto dei rendimenti e fornitura dei dati per la visualizzazione da visualizzare.
    • Elaborazione degli ordini e memorizzazione nel modello.

Se ciò è corretto, dovrebbe essere possibile fornire più componenti di visualizzazione senza modificare il modello o la logica aziendale. Ad esempio, se il progetto corrente è un sito Web, un nuovo server di visualizzazione per un iPhone o un'applicazione Android utilizzerà il modello e la business logic esistenti. Questi possono introdurre nuove funzionalità aziendali per fornire notifiche push quando un ordine è soddisfatto, il che potrebbe richiedere modifiche a più livelli.

Questa ripartizione consente la separazione delle preoccupazioni.

  • Il livello dati rappresentato dal modello tende ad essere relativamente stabile.
  • Il livello aziendale è il luogo 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?
  • Lo strato di visualizzazione tende ad essere meno stabile e potrebbe essercene più di uno. Questo è dove risiede l'aspetto grafico dell'applicazione. È possibile ridefinire completamente un'applicazione, senza modificare gli altri livelli.
risposta data 03.01.2015 - 01:23
fonte

Leggi altre domande sui tag