Quindi forse la risposta rapida è "Sì" assolutamente (o no, suppongo), ma lascia che ti spieghi la mia angolazione di domanda per ottenere una risposta migliore.
Tutti noi usiamo comunemente i principi di progettazione SOLID quando compongono i pezzi e le parti delle nostre applicazioni. Non fare una classe fare troppe cose, non rendere una interfaccia troppo grande, usare l'astrazione non le concrezioni, ecc.
È corretto applicare questa mentalità ad un livello astratto quando si pensa a soluzioni, servizi, ecc.? Il problema principale: sto lottando con la richiesta di fare un singolo servizio per fare tutto ciò che riguarda uno specifico dominio aziendale. Aggiungete a questo più team che avrebbero tutti le mani nel piatto della stessa applicazione per aggiungere qualsiasi funzionalità necessaria.
Ho in mente un servizio con molti buoni principi di architettura e design e credo che molte funzionalità "aggiuntive" potrebbero essere imbullonate verticalmente all'interno dello stesso framework e soluzione. Dopotutto, uno dei motivi per cui trascorriamo del tempo le soluzioni di architettura da accoppiare liberamente e consentire la scalabilità con facilità. Quindi potresti dire: "prendilo, se il framework può gestirlo e poi aggiungere!"
Qualcosa non mi sta proprio bene e sarei interessato a un colosso di un'applicazione / servizio che cerca di fare tutto. Ho provato a fare ricerche su "applicazioni che fanno troppo" o "servizi che hanno troppe responsabilità", ma non è venuto fuori molto. Quando comincio a pensare ai principi SOLID, penso che avere un servizio che tutto correlato a uno specifico dominio aziendale potrebbe non essere una buona idea e che potrebbe causare problemi su strada con manutenibilità e stepping su ogni le dita degli altri.
È corretto utilizzare i principi SOLID quando si esamina l'intera funzionalità della soluzione? La creazione di un servizio come http://www.mycompany.com/api/[everMethodPossible] è corretta, oppure potrei fare qualcosa che non è corretto?
Grazie!