Disaccoppiamento delle dipendenze esterne

Question

Disaccoppiamento delle dipendenze esterne

#1 da (3 voti)
#2 da (1 voti)

1

Abbiamo una semplice webapp REST che dipende da più servizi esterni, principalmente i messaggi di Kafka. È stato effettuato un tentativo di isolare le dipendenze esterne incapsulando tutte le interazioni esterne in una webapp separata e rendere l'app principale comunicante con l'app per interfacce esterne solo attraverso un argomento interno di kafka.

    ----------                                   ---------------
   | core app |  <---Internal kafka topic --->  | external      | <--> external kafka topics 
   |          |                                 | interfaces app| 
    ----------                                   ---------------

Ora stiamo lentamente incontrando sempre più requisiti in cui dovremmo effettuare chiamate sincrone a sistemi esterni, alcuni REST, alcuni SOAP. Aggiungendo questo tipo di richieste attraverso l'app per interfacce esterne e rileggendo i risultati tramite una scala interna di argomento kafka? Quali sono le altre strategie che possiamo usare qui per disaccoppiare le dipendenze esterne?

design enterprise-architecture

posta Rnet 06.02.2016 - 12:01

fonte

2 risposte

Leggi altre domande sui tag design enterprise-architecture

Scheme: Lambda all'interno dell'elenco quotato non è associato Impedire ai miei clienti di dare o vendere il mio software utilizzando una libreria LGPLv3 ad altri

score 3 · Answer 1

Per quanto riguarda il disaccoppiamento, ciò che si potrebbe desiderare è creare un livello adattatore / astrazione presente solo nel pacchetto dell'app principale e fare in modo che l'app principale dipenda da questo livello appena creato.

Spostare la gestione di Kafka in un progetto diverso non è una cattiva idea, tuttavia, anche in questo caso l'app principale non dovrebbe dipendere direttamente da questa nuova applicazione Web, ma fornire il livello di astrazione per l'applicazione interna e quindi usare questa astrazione strato nel suo codice.

La regola empirica, in una lingua con spazi dei nomi, nel caso in cui un progetto abbia sempre il proprio spazio dei nomi di base, con il quale può essere identificato, oltre a un livello di pacchetti o moduli (o qualsiasi cosa tu chiami il livello nel tuo codice), livelli fornendo il livello di astrazione per dipendenze esterne, l'applicazione dovrebbe dipendere solo da classi dello stesso spazio dei nomi di base.

Quindi in un progetto A, che utilizza il progetto B, creo un livello di moduli che astragga il livello B in base alle mie esigenze, adatto a ciò che richiede il progetto A, e quindi uso questo livello astratto nella base di codice A.

Successivamente nel progetto C, che utilizza il progetto A, creerei di nuovo uno strato di astrazione nascondendo in modo efficace la dipendenza A fornendo un'interfaccia dell'adattatore.

Facendo ciò, non ti importa molto dei piccoli cambiamenti nelle dipendenze esterne (rinominazione del metodo, spostamento degli argomenti del metodo, ...), perché è tutto in un unico posto, solo il livello di astrazione dei moduli, quindi il la correzione è molto semplice.

score 1 · Answer 2

Dovrebbe scalare perfettamente, se si effettuano chiamate asincrone all'app wrapper. Se stai effettuando chiamate sincrone, sei limitato dal tempo di risposta del servizio esterno e della rete. Non hai molto controllo su questo.

Tuttavia, effettuando una chiamata al wrapper e non aspettando una risposta, è possibile eseguire il resto dell'elaborazione e attendere una risposta o un ritorno prima che la risposta sia ricevuta. Il modo in cui funziona dipende dalle tue esigenze ma potresti restituire i dati della pagina principale e mantenere un segnaposto per i dati esterni, utilizzando un'altra richiesta con lo stesso riferimento per tentare di aggiornare la sezione se i dati alla fine restituiscono.