Vorrei sapere che cosa differenzia una classe di servizio da una classe di utilità o una classe helper? Una classe solo con metodi sottostanti chiama il dao è un servizio? L'utilizzo delle classi Helper non viola l'SRP?
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à nell'applicazione. Questo è in genere pubblico, con un significato aziendale. Ad esempio, un'interfaccia TicketingService potrebbe consentire di selezionare buyTicket , sellTicket e così via.
Una classe helper tende a essere nascosta dal client e viene utilizzata internamente per fornire un lavoro di piastra di riscaldamento che non ha alcun significato di dominio aziendale. Ad esempio, supponiamo di voler convertire una data in un timestamp per salvarlo nel tuo particolare archivio dati. Potresti avere una classe di utilità chiamata DateConvertor con un metodo convertDateToTimestamp che esegue questa elaborazione.
I servizi non sono semplicemente strettamente associati ai DAO, è un termine / schema di utilizzo più ampio della persistenza
Le classi di aiuto non violano SRP se codificate in base a 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 qualche contesto all'interno dell'applicazione, mentre gli helper sono più generici e non si preoccupano di quale app stanno aiutando.
Per me, vado da La definizione di Eric Evans di service che è qualcosa del genere:
Generalmente, in un sistema ben progettato, la maggior parte delle classi (nel modello di dominio) hanno una responsabilità o una funzione abbastanza chiara in quanto trattano con un'entità specifica o un insieme di entità nel modello.
cioè.
Quando hai funzionalità che non appartengono a una particolare entità, può essere difficile trovare un posto adatto dove sedersi. I.e qualcosa che incapsula un processo che coinvolge sia Account AND a Customer .
Quindi, ecco dove arriva un service . È dove inserisci il codice che si trova nel modello di dominio ma non appartiene naturalmente a un'entità / componente o altro.
Penso a helper come a una specie di classe strategica. Per me è un posto dove mettere il codice che deve essere riutilizzato da varie classi, ma che potrebbe non adattarsi bene come metodi astratti all'interno della gerarchia delle classi che lo usano. Personalmente trovo il termine helper un po 'vago e in realtà non li ho nel mio modello. Anche se esistono nelle librerie che uso.
Classe di servizio: contiene la logica aziendale.
Classe helper: questa classe è un tipo di componente riutilizzabile.
Hai mescolato due principi non correlati. I servizi e le classi di supporto non sono collegati. Soprattutto il termine "Service Class" è fuorviante - penso che tu ti stia riferendo a un "Servizio" che è su un livello più alto di astrazione rispetto alle classi. Un servizio è caratterizzato da
"a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description."
Questa definizione cambia leggermente in base al tuo contesto. Tuttavia, il punto critico è che il termine "servizio" si trova su un livello astratto , il livello di architettura e conoscenza del dominio . La "classe helper" è un modello di progettazione (anche se è un anti-pattern in quanto tendono ad evolversi in classi di blob o di dio) facendo riferimento a una classe che incapsula operazioni generiche (notare che questo è su un livello di astrazione inferiore ed è connesso alla conoscenza di applicazioni / soluzioni ). 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 da diffidare è la definizione multipla di "servizio" in DDD:
Servizio dell'applicazione: si trovano nel livello applicazione e comunicano con il dominio e il livello dati, sono l'interfaccia attraverso cui i sistemi / interfacce utente esterne interagiscono con il sistema DDD.
Servizio dominio: può essere utilizzato dal dominio o dal livello applicazione e contiene logica aziendale che non si adatta perfettamente a una particolare entità.
Servizio infrastruttura: vengono utilizzati dal dominio per comunicare con risorse esterne.
Le classi di helper tendono a contenere pezzi di codice o algoritmi che potrebbero essere riutilizzati da più entità, quindi non possono realmente entrare nelle entità senza violare il principio DRY. Probabilmente sono i più vicini ai Servizi di dominio, in quanto riordinano lo stesso scopo (esternalizzando la logica aziendale dalle entità) ma lo fanno per diversi motivi.
Leggi altre domande sui tag design domain-driven-design java