Quanto è essenziale creare un livello di servizio?

Il libro di Martin Fowler "Patterns of Enterprise Architecture" afferma:

The easier question to answer is probably when not to use it. You probably don't need a Service Layer if your application's business logic will only have one kind of client - say, a user interface - and it's use case responses don't involve multiple transactional resources. [...]

But as soon as you envision a second kind of client, or a second transactional resource in use case responses, it pays to design in a Service Layer from the beginning.

I vantaggi che fornisce un livello di servizio è che definisce un insieme comune di operazioni applicative disponibili per diversi client e coordina la risposta in ogni operazione. Nei casi in cui si dispone di un'applicazione che ha più di un tipo di client che utilizza la propria logica aziendale e ha casi d'uso complessi che coinvolgono più risorse transazionali, è opportuno includere un livello di servizio con transazioni gestite.

Con CRM, Vendite e inventario ci saranno molti casi d'uso di tipo CRUD di cui c'è quasi sempre una corrispondenza uno-a-uno con le operazioni del livello di servizio. Le risposte alla creazione, all'aggiornamento o alla cancellazione di un oggetto dominio devono essere coordinate e gestite atomicamente dalle operazioni del livello di servizio.

Un altro vantaggio di avere un livello di servizio è che può essere progettato per l'invocazione locale o remota, o entrambi - e offre la flessibilità necessaria per farlo. Il modello pone le basi per l'implementazione incapsulata della logica aziendale di un'applicazione e l'invocazione di tale logica da parte di vari client in modo coerente. Ciò significa che riduci / rimuovi la duplicazione del codice, poiché i tuoi clienti condividono gli stessi servizi comuni. Puoi potenzialmente ridurre anche i costi di manutenzione: quando la tua logica di business cambia, tu (generalmente) devi solo cambiare il servizio, e non ciascuno dei client.

In sintesi, è utile usare un livello di servizio - più di così penso che nel tuo esempio tu abbia fornito come sembra che tu abbia più client di logica aziendale.

Aggiunta di un livello di servizio perché hai valutato l'idea e concluso l'approccio migliore: buono

Aggiunta di un livello di servizio perché è quello che fanno tutti i ragazzi fantastici: cattivo

Se il tuo istinto dice che non ne hai bisogno, allora non crearne uno.

Uno degli sviluppi più deludenti nel mondo della programmazione negli ultimi 10 anni è che è diventato fastidiosamente orientato alla "moda", con persone che seguono tendenze e bandwagon come se fossero le scarpe di questa stagione. Non cadere in quella trappola. Perché la prossima stagione 'tutti' ti diranno che avresti dovuto progettarlo in un altro modo.

Non c'è niente di sbagliato o giusto con un livello di servizio - è un approccio particolare la cui idoneità dovrebbe essere valutata in base ai suoi meriti tecnici per il progetto in questione. Non sentirti obbligato a sostituire le opinioni degli altri per il tuo giudizio.

Ci sono molti fattori che entrano nella decisione di creare un livello di servizio. Ho creato livelli di servizio in passato per i seguenti motivi.

1. Codice che deve essere riutilizzato da più client.
2. Librerie di terze parti per le quali disponiamo di licenze limitate.
3. Terze parti che necessitano di un punto di integrazione nel nostro sistema.
4. Centralizzazione della logica aziendale duplicata.

Caso 1: state creando una funzionalità di base che deve essere utilizzata da una miriade di client diversi. Il livello di servizio si integra con funzionalità che consentono a diversi client di sfruttare immediatamente le funzionalità fornite.

Caso 2: in genere il codice host viene ospitato nello spazio app ma si utilizza una libreria di terze parti per cui si dispone di licenze limitate. In questo caso hai una risorsa che vorresti usare ovunque, ma solo un numero limitato di essi. Se lo si ospita dietro un servizio, l'intera organizzazione può utilizzarlo dalle proprie applicazioni senza dover acquistare una licenza per ogni singolo hosting.

Caso 3: state creando funzionalità per consentire a terzi di comunicare con voi. Nel tuo esempio potresti configurare un endpoint dell'inventario per consentire ai venditori di passare messaggi relativi alle spedizioni di prodotti in entrata.

Caso 4: hai analizzato il tuo codice a livello aziendale e hai scoperto che i team separati hanno creato la stessa cosa (implementata in modo leggermente diverso). Con un livello di servizio è possibile scegliere l'approccio migliore (i) e ora è possibile implementare il processo allo stesso modo in tutti i team facendoli chiamare al servizio. Un altro vantaggio della logica di centralizzazione è quando vengono rilevati errori. Ora puoi implementare la correzione una volta e tutti i clienti godono del vantaggio allo stesso tempo.

Tutto questo viene detto che esistono potenziali negativi a un livello di servizio.

1. Aggiunge la complessità del sistema. Dove prima hai solo un'applicazione per eseguire il debug ora ne hai due. I problemi di produzione richiedono la verifica dell'impostazione delle app client, delle impostazioni delle app di servizio o dei problemi di comunicazione tra installazioni client e server altrimenti correttamente configurate. Questo può essere complicato se non lo hai mai fatto prima.
2. Un punto di errore. Se si verifica un'interruzione del servizio, tutti i client sono interessati. Quando il codice non viene distribuito in questo modo, il rischio può essere inferiore (sebbene ci siano modi per mitigarlo).
3. Il controllo delle versioni può essere più difficile da fare. Quando si dispone di un'app che utilizza un servizio che distribuisce le modifiche all'interfaccia, è possibile eseguirle contemporaneamente. Quando hai più client ora devi gestire chi è su V1, chi è su V2 e coordinare la rimozione di V1 (una volta che tutti sono aggiornati a V2).

Il punto principale è che non è sempre una schiacciata per rendere orientato il servizio di sistema. Nella mia esperienza di solito è una buona idea (tendo a strutturare le applicazioni in questo modo), ma non è una decisione automatica. Alla fine della giornata devi valutare i pro e i contro e prendere la decisione giusta per la tua situazione.

La maggior parte dei livelli di servizio che ho visto sono un casino completo. I servizi tendono ad avere molti metodi diversi, 1500 LOC non sono rari. I diversi metodi non hanno nulla in comune, ma condividono il codice. Ciò si traduce in un alto accoppiamento , basso la coesione . Inoltre viola OCP , perché ogni volta che è necessaria una nuova operazione, devi modificare il codice invece di estendere il codice base. Un livello di servizio ben costruito è teoricamente possibile, ma non l'ho mai visto in pratica.

CQRS risolve questi problemi e ti impedisce di dover creare uno di questi livelli di servizio procedurale.

L'aggiunta di un'interfaccia (un livello di servizio è un tipo di interfaccia) richiede tempo. Un buon tempo richiede molto tempo per progettare e testare. È molto importante farlo subito al primo tentativo, perché cambiandolo in seguito si rompono tutti i client. Inoltre, considera che probabilmente non saprai cosa deve essere in quell'interfaccia finché non avrai un secondo client con esigenze leggermente diverse. Mantenere un servizio è un progetto senza fine in sé.

Nella maggior parte delle organizzazioni, se vai dal tuo sponsor aziendale e chiedi loro: "Vuoi che altri dipartimenti ottengano il beneficio di (riutilizzare) questo sistema che stiamo sviluppando con il tuo budget?" loro rideranno di te. Procuralo per primo al tuo sponsor aziendale, quindi inizia a giocare con il riutilizzo di quel codice (al momento del tuo dipartimento).

Se sai, per certo, che la funzionalità che stai scrivendo oggi verrà riutilizzata da più client di servizio diversi, quindi considera la progettazione di un livello di servizio sin dal primo giorno. Se non si è sicuri o se ci sono già molte incognite nel progetto, ottenere prima qualcosa di semplice da lavorare e dividerlo in servizio e client in un secondo momento, se si dispone di tempo e budget. È molto più semplice ottenere l'interfaccia di servizio al primo tentativo quando si avvia con un sistema funzionante.

P.S. Se stai lavorando in Java, Joshua Bloch ha un sacco di fantastici consigli per l'interfaccia in tutto il suo libro, Effective Java.

Sono d'accordo con te. Non è necessario includere un altro livello se si utilizza una singola interfaccia utente.

DAL, BL e UI / Controller sono una buona combinazione per progettare un'applicazione. Se hai intenzione di utilizzare un'unica interfaccia utente, non è necessario preparare un ulteriore livello. Includere 1 strato in più nell'applicazione aumenta solo gli sforzi / i tempi di sviluppo.

Un altro schenerio consiste nell'utilizzare più interfacce utente nell'applicazione, in questo caso è utile disporre di un livello di servizio per gestire le interfacce utente.

Overflow dello stack: Discussione sul modello del livello di servizio

Vorrei contestare che il tuo BL è il tuo livello di servizio. Un luogo centrale in cui si trova la tua logica aziendale. Questa dovrebbe essere una DLL che può essere utilizzata da qualsiasi cosa abbia bisogno di quella logica. Quindi puoi aggiungere un livello API Web se la tua app avrà interfacce utente diverse.