Code Design: microservice - Servizi perdenti Principio della singola responsabilità

4

Sto cercando di implementare Microservice per capire l'architettura e come funziona la comunicazione. Molti articoli affermano che i servizi dovrebbero seguire il principio della singola responsabilità, ma è piuttosto difficile da ottenere. Ad esempio, devo cercare Item e ottenere tutte le informazioni (incluso lo stock).

Quindi ho due servizi:

  • Un servizio oggetti che si occupa di tutto ciò che riguarda l'oggetto. Ha sotto-servizi come ItemSearchService , ItemCreationService , ecc.
  • Un servizio di magazzino il cui compito è aggiornare le scorte, ottenere informazioni sui titoli ecc.

Va bene se lo faccio:

  • Una chiamata di riposo a ItemSearchService.searchById()
    • Ciò otterrà le informazioni (escluse le informazioni di borsa)
  • Una chiamata di riposo a StockService.getStockCount()
    • Ciò otterrà informazioni di borsa
    • Il controllo viene restituito a ItemSearchService , dove le informazioni del servizio di borsa vengono aggregate e viene restituito il risultato di ricerca

La mia preoccupazione: sta infrangendo il principio della singola responsabilità? Perché la responsabilità di ricerca è solo per cercare, e qui si ottengono anche le informazioni di borsa.

    
posta user784530 18.12.2016 - 21:39
fonte

2 risposte

4

Il principio di responsabilità unica è ampiamente frainteso. Non afferma che un oggetto o servizio dovrebbe "fare solo una cosa". Piuttosto, afferma che dovrebbe avere solo un "motivo per cambiare", dove "il motivo per cambiare" indica una decisione aziendale o un problema tecnico che potrebbe costringerti a cambiare il codice o, in questo caso, cambiare l'interfaccia del servizio. / p>

Quindi se tu avessi un servizio chiamato numberOfAvailableBlueCapsAtNewJerseyWarehouse() , interromperesti l'SRP perché questo metodo dovrebbe cambiare se cambia l'elemento del prodotto (ad es. i tappi non sono più disponibili in blu) o il magazzino del New Jersey è dismesso . Pertanto, i fattori che cambiano frequentemente come prodotti e magazzini potrebbero essere configurati in dati piuttosto che codificati in un'interfaccia di servizio.

    
risposta data 19.12.2016 - 14:54
fonte
0

Non ho mai sentito SRP menzionato prima nel contesto dei micro-servizi. Sicuramente non ha bisogno di essere così draconico come sembra, però. Quando scrivi MSE, devi pensare quali parti del codice possono e devono essere accoppiate / ridimensionate / distribuite insieme? Nel tuo caso, gli articoli possono esistere senza stock? Ti dà benefici per separarli? Ha senso nel tuo dominio separarli o tenerli separati?

Dato che stai scrivendo il codice del concetto per percepire l'architettura e il modo in cui funziona la comunicazione, io dico di impazzire e di refactarlo quanto vuoi. In questo modo avresti una sensazione per aspetti come

  • spostamento della complessità dal codice all'ambiente
  • prestazioni
  • integrità dei dati
  • operazioni, dev-ops
  • gestione della pipeline di build

ecc ...

    
risposta data 19.12.2016 - 12:19
fonte

Leggi altre domande sui tag