Solitamente, i servizi chiamano altri servizi quando devono accedere ai propri dati. Ogni pezzo di dati dovrebbe appartenere a un particolare servizio che sarà l'unico punto di accesso per accedere a questi dati e modificarli. Alcuni servizi saranno semplici e di solito corrispondono strettamente al modello del tuo dominio (ad esempio un servizio per la gestione degli utenti) mentre altri saranno di alto livello e utilizzeranno i dati di altri servizi (ad esempio visualizzando un elenco di foto insieme a informazioni sugli utenti che li hanno caricati) ).
Nel tuo caso d'uso, dovresti iniziare dall'esterno e pensare a quali operazioni vuoi rendere disponibili all'utente tramite un'API (se si tratta di un servizio di back-end) o quali operazioni dovrebbero essere disponibili nella GUI se si tratta di un Web applicazione. Si noti che la parte della GUI è spesso un'applicazione regolare con i propri controllori: le operazioni possono essere chiamate tramite REST (come in AngularJS), ma questi endpoint sono progettati solo per l'uso dell'applicazione della GUI e non sono microservizi nel senso comune.
Supponiamo di voler visualizzare le foto insieme alle informazioni sugli uploader. Potresti avere un servizio utente che restituisce informazioni su un utente, dato l'ID dell'utente e un servizio fotografico che può elencare le foto (ad es. Cercando in base a determinati criteri). L'elenco di foto conterrebbe per ogni foto l'ID dell'utente che effettua il caricamento. In questo modo questi due servizi non sono accoppiati: il servizio fotografico conosce solo gli ID utente ma nulla sui dati dell'utente stessi. Oltre a questi due servizi, è possibile creare un terzo servizio con un'operazione come "elenca le foto con informazioni sugli uploader" che chiamerebbe gli altri due servizi e combinerebbe i dati restituiti. In alternativa, questa operazione potrebbe essere eseguita dall'applicazione Web anziché da un servizio.