È buona o cattiva pratica condividere i moduli di segnalazione tra sistemi / app?

Question

È buona o cattiva pratica condividere i moduli di segnalazione tra sistemi / app?

#1 da (3 voti)

3

Al mio nuovo lavoro, alcune persone vogliono condividere moduli tra sistemi / app e sono un po 'scettico al riguardo.

Contesto: abbiamo un sacco di piccole app che vivono in server diversi, alcune di loro sono scrappers, alcune solo app web ecc ... sono anche lingue diverse (java, javascript, php, python) forse il l'unica cosa che hanno in comune è l'esportazione in csv / xlsx per diversi client.

Quindi l'idea era di creare un "modulo di esportazione" condiviso che ogni sistema / app potesse utilizzare.

Il nuovo flusso di lavoro è che desiderano creare:

raschia / elabora i dati
memorizza queste informazioni nel db (ha senso per me)
quindi con un modulo unico crea l'"output" che in questo momento ogni app sta creando da solo.

L'ultima parte è quella in cui sono insicuro, la parte in cui un modulo univoco (forse nodeJS) tenta di ottenere l'output corretto per sistemi diversi con diverse logiche di business, ad esempio alcuni scraper creano un file con l'ultimo lunedì della settimana nel nome, un altro crea semplicemente un file csv con "oggi" nel nome.

È possibile condividere un modulo in quel punto, o è meglio se ogni app è indipendente e atomica?

Riepilogo: due opzioni

1) Sistemi multipli in lingue diverse memorizzano i dati nel db, quindi un modulo unico crea l'output da essi

2) Ogni sistema con la sua "propria" libreria da esportare in csv, per eccellere, ecc ... se necessario? (ancora salvando i dati nel db)

design programming-practices architecture design-patterns patterns-and-practices

posta GVB 11.09.2018 - 14:58

fonte

1 risposta

Leggi altre domande sui tag design programming-practices architecture design-patterns patterns-and-practices

Estratto genitore ed ereditarietà rispetto al modello e alla composizione della strategia È necessario aggiornare EICAR per verificare la revisione del sistema antivirus?

score 3 · Accepted Answer

Un principio da considerare è che se stai scrivendo in più lingue, dovrai trovare una squadra in grado di supportare più lingue. Non è la preoccupazione più grande, ma vale la pena menzionarla. Ho lavorato in luoghi in cui volevo usare golang per un microservizio di piccole dimensioni, ma si è deciso di restare con Java dato che avevamo un certo numero di esperti Java sullo staff e trovare un backfill per quella posizione sarebbe stato facile.

La prima domanda che vorrei porre è: "Quale problema viene risolto qui?" Sembra che quello che vogliono fare è avere un modulo di esportazione in modo che possano ESSERE DRY (non ripeterti) sul codice. Questa è una buona cosa da fare; aiuta con la mantenibilità. Ma qual è il problema più grande qui? È manutenibilità?

Inoltre, quanto sono diverse le strutture dati che devono andare al cliente? In che modo i clienti accedono ai dati (allo stesso modo o in modi diversi)? Penso che questi potrebbero anche indicarti una decisione.

I microservizi possono essere un buon paradigma da considerare qui. Ogni app potrebbe essere il proprio servizio e il microservizio "ETL" potrebbe caricare i dati in diverse tabelle di database. Diversi endpoint Web potrebbero accedere alle diverse tabelle.

In definitiva, penso che l'affermazione del problema debba essere pensata prima di prendere una decisione, ma entrambi gli approcci potrebbero essere utili.