Dove dovrebbero trovarsi le chiamate HTTP in un'architettura a livelli?

4

Ho un client che dipende dal recupero dei dati da due domini diversi. Il cliente recupera i dati dal livello API "A" del dominio e i dati del dominio "A" dipendono dal dominio "B"

Esiste un'implementazione sul livello dei servizi "A" del dominio per chiamare HTTP Richiedi livello dominio API" B ".

Quello che ritengo è che dovremmo recuperare i dati utilizzando le chiamate HTTP dal livello API e non dovremmo spostarlo sul livello di servizio e lo vedo come un pattern anti.

Quale dovrebbe essere il modo più accettabile per andare avanti con questo scenario?

    
posta Kalanamith 02.11.2016 - 08:27
fonte

2 risposte

4

Il livello API rappresenta l'API che offri al client.

Se la chiamata al dominio B è solo l'inoltro di una richiesta client senza valore aggiunto, è effettivamente qualcosa che è possibile gestire nel livello API, che funge da facade fai il cliente.

Se la chiamata contribuisce effettivamente al servizio che fornisci, sono necessari ulteriori pensieri:

  • Capisco che ti piacerebbe vedere il tuo livello API come un livello gateway, che gestisce tutte le comunicazioni con il mondo esterno à-la architettura esagonale . Potresti farlo, ma ti consiglio comunque di fare la differenza perché le chiamate in entrata e in uscita sono di natura diversa (ad esempio, disegna due slot nello stesso livello).

  • Potresti anche considerare la domanda più in generale sopra tutti i domini e prendere in considerazione una sorta di " bus di servizio "/ livello di messaggistica indipendente dal dominio A e dal dominio B o da un generale gateway API .

risposta data 02.11.2016 - 11:27
fonte
0

Se desideri implementare l'applicazione nell'architettura SOA, è meglio chiamare un servizio da un processo aziendale chiamato orchestrazione del servizio. potreste pensare ad esso come simile al Controller in pattern MVC

    
risposta data 02.11.2016 - 08:59
fonte