Che cosa consiste esattamente nella "logica aziendale" in un'applicazione?

Question

Ho sentito innumerevoli volte che "non dovremmo mescolare la logica aziendale con altri codici" o affermazioni del genere.Penso che ogni singolo codice che scrivo (intendo le fasi di elaborazione) sia costituito da una logica correlata ai requisiti aziendali.

Qualcuno può dirmi in cosa consiste esattamente la logica aziendale?Come si distingue dagli altri codici?Esiste qualche semplice test per determinare cos'è la logica aziendale e cosa no?

Answer 1

Definisci semplicemente cosa stai facendo in un inglese semplice.Quando dici cose dal punto di vista commerciale, come "far soffrire quelli", "rubare quei soldi", "distruggere questa porzione di terra", stai parlando del livello degli affari.Per essere chiari, le cose che ti entusiasmano vanno qui.

Quando dici "mostra questo qui", "non mostrare quello", "rendilo più bello" stai parlando del livello di presentazione.Queste sono le cose che entusiasmano i tuoi designer.

Quando dici cose come "salva questo", "prendilo dal database", "aggiorna", "elimina", ecc.stai parlando del livello dati.Queste sono le cose che ti dicono cosa conservare per sempre a tutti i costi.

Answer 2

Probabilmente è più semplice iniziare dicendo cosa non lo è logica di business.L'accesso al database o al disco non è una logica aziendale.L'interfaccia utente non è la logica aziendale.Le comunicazioni di rete non sono una logica aziendale.

Per me, la logica aziendale è costituita dalle regole che descrivono come opera un’azienda, non come opera un’architettura software.Anche la logica aziendale ha la tendenza a cambiare.Ad esempio, potrebbe essere un requisito aziendale che ogni cliente abbia una singola carta di credito associata al proprio account.Questo requisito potrebbe cambiare in modo che i clienti possano avere più carte di credito.In teoria, questa dovrebbe essere solo una modifica alla logica aziendale e altre parti del software non saranno interessate.

Quindi questa è teoria.Nel mondo reale (come hai scoperto) la logica aziendale tende a diffondersi in tutto il software.Nell'esempio sopra, probabilmente dovrai aggiungere un'altra tabella al tuo database per contenere i dati extra della carta di credito.Dovrai sicuramente modificare l'interfaccia utente.

I puristi sostengono che la logica aziendale dovrebbe essere sempre completamente separata e quindi sarebbero addirittura contrari all'inserimento di tabelle denominate "Clienti" o "Conti" nel database.Portato alle sue estreme conseguenze, ti ritroveresti con un sistema incredibilmente generico e impossibile da mantenere.

C'è sicuramente un forte argomento a favore di tenere insieme la maggior parte della logica aziendale piuttosto che spargerla in tutto il sistema, ma (come con la maggior parte delle teorie) è necessario essere pragmatici nel mondo reale.

Answer 3

Penso che tu stia confondendo la logica aziendale con i requisiti della tua applicazione.Non è la stessa cosa.Quando qualcuno spiega la logica della sua attività è qualcosa del tipo:

"Quando un utente acquista un articolo deve fornire informazioni sulla consegna.Le informazioni vengono convalidate con le regole x y z.Successivamente riceverà una fattura e guadagnerà punti, che gli darà x% di sconto per le y offerte" (scusate il cattivo esempio)

Quando implementi queste regole aziendali dovrai pensare a requisiti secondari, come come vengono presentate le informazioni, come verranno archiviate in modo persistente, la comunicazione con i server delle applicazioni, come l'utente riceverà la fattura e così via.Tutti questi requisiti non fanno parte della logica aziendale e dovrebbero essere disaccoppiati da essa.In questo modo, quando le regole aziendali cambiano, adatterai il tuo codice con meno sforzo.Questo è un fatto.

A volte la presentazione replica parte della logica aziendale, principalmente nella convalida dell'input dell'utente.Ma deve essere presente anche nel livello della logica aziendale.In altre situazioni, è necessario spostare parte della logica aziendale nel database, per problemi di prestazioni.Questo è discusso da Martin Fowler Qui.

Answer 4

Per semplificare le cose in una sola riga...
La logica aziendale sarebbe un codice che non dipende/non cambierà con un'interfaccia utente/dettagli di implementazione specifici.È una rappresentazione in codice di regole, processi, ecc.che sono definiti/riflettono l'azienda modellata.

Answer 5

Non mi piacciono i nomi BLL+DAL dei livelli, sono più confusi che chiarificatori.
Chiamatelo DataServices e DataPersistence.Questo renderà tutto più semplice.

I servizi manipolano i CRUD del livello di persistenza (Crea, Leggi, Aggiorna, Elimina)

Answer 6

Per me, " logica di business " costituisce tutte le entità che rappresentano i dati applicabili al dominio problematico, nonché la logica che decide "cosa fare con i dati".

Quindi in realtà dovrebbe consistere in "trasporto di dati" (non accesso) e "manipolazione dei dati".In realtà l'accesso ai dati (cose che colpiscono il DB) dovrebbe trovarsi in un livello diverso, così come il codice di presentazione.

Answer 7

Se contiene qualcosa su cose come modulo, pulsante, ecc.non è una logica aziendale, è il livello di presentazione.Se contiene persistenza su file o database, è DAL.Tutto ciò che sta nel mezzo è logica aziendale.In realtà, tutto ciò che non è UI a volte viene chiamato "logica aziendale", ma dovrebbe essere qualcosa che riguarda l'ambito del problema, non la gestione interna.

Answer 8

La logica aziendale è pura astrazione, esiste indipendentemente dalla materializzazione/visualizzazione dei dati di fronte all'utente e dalla persistenza dei dati sottostanti.

Ad esempio, nel software di preparazione fiscale, una delle responsabilità delle classi di logica aziendale sarebbe il calcolo delle imposte dovute.Non sarebbero responsabili della visualizzazione di report o del salvataggio e del recupero di una dichiarazione dei redditi.

---

@Lars, "servizi" implica una certa architettura.