Sto sviluppando un sito Web MVC in PHP e per la prima volta vorrei implementare un livello di servizio. Ho alcune considerazioni di progettazione su cui vorrei avere qualche consiglio. Il back-end non sarà affatto un grande sistema aziendale, quindi cerco di mantenere le cose relativamente semplici sfruttando ancora i vantaggi di un livello di servizio.
L'idea è che i miei controller interagiranno con i servizi, che a loro volta interagiranno con i DAO. La mia domanda principale è quanto dovrebbero essere granulari i miei servizi. Ho familiarità con il concetto di granularità del servizio in SOA, ma non l'ho mai implementato nella pratica. Ad esempio, per gestire la registrazione dell'utente, dovrei avere una classe RegistrationService o dovrei avere un UserService che contiene un metodo register insieme ad altri servizi relativi all'utente? L'approccio precedente significa che avrò un livello di servizio pieno di servizi piccoli o a grana fine, ma suppongo che sia una buona cosa. Quest'ultimo sembra ostacolare il riutilizzo del servizio e portare a grandi classi con molti metodi.
Invece, forse dovrei combinare i due approcci per garantire che i miei servizi possano essere riutilizzati? Ad esempio, avere un RegistrationService che interagisce con una classe DAO. Quindi, potrei avere una classe UserService con un metodo register . Questo metodo interagisce con RegistrationService a grana fine. In questo modo, RegistrationService può essere facilmente riutilizzato per comporre più servizi a grana grossa. Sicuramente ci sono esempi in cui il riutilizzo sarebbe più probabile; per esempio, un ordine dovrebbe utilizzare / orchestrare molti servizi diversi. Immagino che si possa definire un approccio "stratificato", che ho già visto in precedenza. Posso strutturarlo in modo tale che il mio livello di servizio non diventi un disastro?
Mi piacerebbe sentire le tue opinioni su questo, se hai altri suggerimenti, raccomandazioni, esperienze o commenti sulle idee che ho presentato sopra. Grazie in anticipo.