Qual è la differenza tra business e logica dell'applicazione? [chiuso]

Sono d'accordo con LoztInSpace di SO che questa è una risposta piuttosto opinata e che ognuno può avere definizioni leggermente diverse. Soprattutto se sono coinvolte influenze storiche. Ecco come definirei i termini:

La logica aziendale è logica, creata con la collaborazione e l'accordo con esperti di business. Se un esperto di business dice che "il Cliente non può prelevare più denaro di quello che ha nel suo account", allora questa è una regola aziendale. Nel mondo ideale, questa logica si trova in una sorta di libreria o servizio, quindi può essere riutilizzata in più applicazioni o modificata in tutte le applicazioni rilevanti contemporaneamente.

La logica dell'applicazione è semplicemente tutto il resto. L'esempio può essere "facendo clic su questo pulsante si apre la finestra per aggiungere un nuovo cliente". Non ha nulla a che fare con il business, ma è ancora logico che deve essere implementato. Nel mondo ideale, la logica applicativa utilizzerà la libreria o il servizio, ovvero l'implementazione delle regole aziendali. Applicazioni multiple, ognuna con una diversa logica applicativa, possono riutilizzare una logica aziendale. Immagina che l'app web, il servizio web e l'app mobile funzionino tutti utilizzando un'unica logica di business, ma ognuno ha chiaramente bisogno di diverse logiche applicative.

Il motivo per cui penso che questi due si confondano, è che tenerli separati è estremamente difficile. Anche se fai del tuo meglio per tenerli separati, usa la superficie dei casi in cui devi mescolarli. Se ad esempio hai tutta la tua logica aziendale in servizio, la mantiene separata. Ma avere una certa logica di business nell'applicazione locale che sta utilizzando il servizio potrebbe aumentare la reattività o il comfort dell'utente, perché l'applicazione locale non ha bisogno di chiamare il servizio per ogni piccola modifica.

Un altro motivo per cui sono mescolati insieme è quello per molte persone non tecniche. L'interfaccia utente è "l'applicazione", quindi qualsiasi cosa riflessa nell'interfaccia utente è importante. Nel caso ideale di "logica aziendale", non esiste un'interfaccia utente. Probabilmente ci sarebbe una suite di test automatici per verificare la logica, ma nulla che possa essere mostrato agli uomini d'affari. Quindi per gli uomini d'affari, tutto è lo stesso tipo di "logica". IMO.

Na, sono solo termini diversi per la stessa cosa: il "livello intermedio" del codice del programma che fa ciò che vuoi che il tuo programma esegua. Come molte cose nel software, non ci sono terminologia hard-and-fast per pezzi di un sistema, poiché non ci sono definizioni formali uniche per i sistemi di costruzione.

Quindi a volte le persone lo chiamano logica di business, altre applicazioni logiche, altre la chiamano logica di programma, è tutto molto più di una cosa. Non preoccuparti di cercare di definire questo in modo così rigido, quasi ogni sistema varia nel modo in cui è costruito, quindi sii contento che c'è solo un livello minore di vaghezza nella terminologia!

Come altri hanno sottolineato, questi termini non hanno un significato universalmente accettato. Descriverò le definizioni che ho incontrato più spesso, cioè in diversi progetti con diverse aziende.

La logica aziendale definisce un modello normalizzato e generico del dominio aziendale per il quale viene scritta un'applicazione, ad es.

• Classi come Customer , Order , OrderLine e associazioni come customer-order e così via.
• Operazioni generiche come registerCustomer , cancelOrder

Molto spesso questo modello di classe è mappato su un modello di database e la mappatura è implementata usando ORM. Le operazioni vengono normalmente eseguite ciascuna nella propria transazione e forniscono l'API di base per la modifica del database, ovvero lo stato persistente dell'applicazione.

La logica dell'applicazione è un livello costruito sulla base della logica aziendale e serve a implementare casi d'uso specifici. I moduli di logica applicativa possono utilizzare la rappresentazione di dati ad-hoc, ad es. una classe CustomerSummary senza alcuna associazione a Order se si desidera elencare solo i clienti. Tale rappresentazione dei dati ad-hoc deve essere associata alla rappresentazione normalizzata sottostante fornita dal modello di business. Ad esempio, CustomerSummary può essere definito come una vista sopra Customer .

Si noti che il confine tra i due livelli potrebbe non essere definito in modo così chiaro. Per esempio. dopo aver implementato diversi casi d'uso, si potrebbero notare strutture di dati simili nella logica dell'applicazione e decidere di unificarle (normalizzarle) e spostarle nella logica di business.

Ogni sistema o applicazione avrà le proprie definizioni di cosa sia la logica aziendale e quale sia la logica dell'applicazione. Sarà esplicito o implicito.

Nella mia esperienza le applicazioni basate sui dati (ad es. DB, ecc.) tendono ad avere una definizione più formale di quale sia la logica aziendale.

La logica dell'applicazione tende a concentrarsi sull'acquisizione di informazioni dal punto A al punto B, la logica aziendale si concentra su ciò che l'informazione è - e la lingua della logica aziendale è solitamente specifica del dominio. In altre parole, la logica dell'applicazione è incentrata sulla domanda "come funziona?", La logica aziendale su "che cosa fa?" - di nuovo, la distinzione può essere molto confusa ed è più spesso che non è specifica del dominio.