Risposte:
Le linee possono essere un po 'sfocate, ma la vedo così:
Una classe / interfaccia di servizio fornisce un modo per un client di interagire con alcune funzionalità dell'applicazione. Questo è in genere pubblico, con qualche significato commerciale. Ad esempio, TicketingServiceun'interfaccia potrebbe consentire buyTicket, sellTickete così via.
Una classe di supporto tende a essere nascosta dal client e viene utilizzata internamente per fornire alcuni lavori relativi alla piastra della caldaia che non hanno alcun significato nel dominio aziendale. Ad esempio, supponiamo che tu voglia convertire una data in un timestamp per salvarla nel tuo particolare archivio dati. È possibile che venga chiamata una classe di utilità DateConvertorcon un convertDateToTimestampmetodo che esegue questa elaborazione.
I servizi non sono semplicemente strettamente associati ai DAO, è un modello / modello di utilizzo più ampio della persistenza
Le classi di supporto non violano SRP se codificate secondo tale principio. Cioè, ogni metodo dovrebbe fare una cosa e una cosa bene, la classe dovrebbe eseguire un tipo di aiuto di utilità (ad esempio la conversione della data) e farlo bene.
Non una definizione scientifica, ma la mia opinione generale è che una classe di servizio ha un certo contesto all'interno dell'applicazione, mentre gli helper sono più generici e non si preoccupano dell'app che stanno aiutando.
Per me, vado dalla definizione di Eric Evans,service che è qualcosa del genere:
Generalmente, in un sistema ben progettato, la maggior parte delle classi (nel modello di dominio) hanno responsabilità o funzioni abbastanza chiare in quanto trattano di una specifica entità o serie di entità nel modello.
vale a dire
Quando si dispone di funzionalità che non appartengono a nessuna entità particolare, può essere difficile trovare un posto corretto in cui sedersi. Vale a dire qualcosa che incapsula un processo che coinvolge sia un AccountAND a Customer.
Quindi, è qui che serviceentra in gioco. È dove si inserisce il codice che si trova nel modello di dominio ma che non appartiene naturalmente a un'entità / componente o a un'altra.
Penso a helperuna specie di classe strategica. Per me è un posto dove mettere il codice che deve essere riutilizzato da varie classi ma potrebbe non essere del tutto adeguato ai metodi astratti all'interno della gerarchia delle classi che lo usano. Personalmente trovo il termine helperun po 'vago e non li ho davvero nel mio modello. Sebbene esistano nelle librerie che uso.
Classe di servizio: contenere la logica aziendale.
Classe di supporto: questa classe è un tipo di componente riutilizzabile.
Hai confuso due entità non correlate. I servizi e le classi di supporto non sono collegati. Soprattutto il termine "Classe di servizio" è fuorviante - penso che ti riferisca a un "Servizio" che ha un livello di astrazione più elevato rispetto alle classi. Un servizio è caratterizzato attraverso
"un meccanismo per consentire l'accesso a una o più capacità, in cui l'accesso è fornito utilizzando un'interfaccia prescritta ed è esercitato in conformità con vincoli e politiche come specificato dalla descrizione del servizio."
Questa definizione cambia leggermente a seconda del contesto. Tuttavia, il punto critico è che il termine "servizio" è a un livello astratto , il livello di conoscenza dell'architettura e del dominio . "Helper Class" è un modello di progettazione (anche se è un anti-modello in quanto tendono ad evolversi in classi blob o god) facendo riferimento a una classe che incapsula operazioni generiche (si noti che questo è a un livello inferiore di astrazione ed è collegato alla conoscenza dell'applicazione / soluzione ). Sono consapevole del fatto che non esiste quasi nessun software che non contenga alcun tipo di classe di supporto, ma è comunque una cattiva pratica.
Una cosa di cui diffidare sono le molteplici definizioni di "servizio" in DDD:
Servizio applicazione: si trovano nel livello applicazione e comunicano con il dominio e il livello dati, sono l'interfaccia attraverso la quale i sistemi esterni / UI interagiscono con il sistema DDD.
Servizio di dominio: può essere utilizzato dal dominio o dal livello applicazione e contiene una logica aziendale che non si adatta perfettamente a una particolare entità.
Servizio infrastruttura: sono utilizzati dal dominio per comunicare con risorse esterne.
Le classi di supporto tendono a contenere parti di codice o algoritmi che potrebbero essere riutilizzati da più entità, quindi non possono realmente entrare in entità senza violare il principio DRY. Probabilmente sono i più vicini ai Servizi di dominio, in quanto ordinano di soddisfare lo stesso scopo (esternalizzare la logica aziendale dalle entità) ma lo fanno per motivi diversi.