Architettura orientata ai servizi - Responsabilità dei componenti

Se il front end è responsabile per il "grande payload" per l'elaborazione da parte del back-end Python, si ha un alto grado di accoppiamento tra i due sistemi che significa che la manutenzione, la gestione delle modifiche o il refactoring diventano più complessi poiché entrambi i lati della comunicazione richiedono una riprogettazione interdipendente significativa per gestire l'invio e la ricezione dei dati.

Inoltre, implicitamente, un nuovo archivio dati viene creato nei protocolli di trasmissione (anche se transitorio) mentre i dati sono formattati dal front-end, trasmessi e analizzati dal back-end.

Inviando solo l'indice nei dati del database rimuovi il problema di un strong accoppiamento e le modifiche a entrambe le estremità del processo possono avvenire con (solitamente) poca dipendenza dall'altra parte. Inoltre, sono presenti meno errori di insinuazione perché non vi è alcuna formattazione di messaggi di grandi dimensioni e quindi l'analisi di tali messaggi. Inoltre, hai una scalabilità facile perché in futuro potresti aggiungere più elaborazione front-end e più elaborazione back-end senza preoccuparti di quali front-end connetterti a quali back-end (che è tutto gestito dalla lettura dei back-end) da un archivio dati comune).

Questo presuppone che tu abbia, e continuerai ad avere, accesso diretto al database da entrambi i sistemi, cioè che non hai intenzione di riposizionare entrambi i lati del dialogo per rimuovere i sistemi in futuro. Se in futuro trasferirai uno dei sistemi dalla connettività diretta al database, allora

Ovviamente i problemi di invio di messaggi di grandi dimensioni come questo sono gestibili (per alcuni sistemi non esiste un accesso diretto a un database condiviso) ma aggiungono un livello di complessità che sembra non sia necessario prendere in considerazione.

Cercherò di evitare qualsiasi soluzione che richieda la condivisione di un database tra il front-end e un servizio back-end, perché la mia esperienza è che i database condivisi causano un accoppiamento molto più difficile da districare rispetto a un formato di scambio complesso .

Presumo che i dati vengano inizialmente raccolti dal front-end e quindi passati al servizio una volta completato l'ordine. In questo caso, legare il servizio back-end tramite il database significa che è probabile che qualsiasi modifica nel formato dei dati richieda sia il front end che il back end per cambiare.

Ci sono anche implicazioni sulla sicurezza. È auspicabile eseguire i servizi nel modo più sicuro possibile; questo spesso significa che vengono eseguiti su una macchina separata per il front-end, che deve essere esposto a Internet in generale. Idealmente, avremmo un database sicuro per il servizio che non è accessibile dal front-end della macchina; questo riduce al minimo le conseguenze di un compromesso al front end (impedendo ad un hacker, ad esempio, di modificare gli ordini già accettati per aggiungere ulteriori oggetti). Questo è più difficile da ottenere se il servizio deve accedere anche al database front-end. Questo potrebbe non essere qualcosa che intendi fare ora, ma scegliendo di passare a soa ottieni questo tipo di flessibilità per i futuri miglioramenti, quindi sarebbe un peccato chiuderli prima di iniziare davvero.