Condivisione di oggetti DTO tra microservizi

Naviga le tue risposte
14

TL; DR - Va bene condividere una libreria POJO tra servizi?

In genere ci piace mantenere la condivisione tra servizi strettamente limitati a nessuno se possibile. Si è discusso se il servizio che condivide i dati debba fornire una libreria client per i client da utilizzare. Il client-lib è generalmente facoltativo per un client del servizio da utilizzare e può consumare l'API, a loro piacimento, sia che si usi il client-lib, sia che si usi una lingua alternativa e si utilizzino gli aspetti generali della libreria e simili.

Nel mio caso - considero un servizio che crea un oggetto di dati. Supponiamo che questo oggetto sia un PET. NON è l'entità del database, ma strettamente un POJO che rappresenta implicitamente i dati sottostanti. Questo POJO è ciò che l'API ha definito. Assumi: Pet - Età, Peso, Nome, Proprietario, Indirizzo, Specie, ecc.

Servizio 1 - PetKeeper: genererà un animale domestico per qualsiasi motivo e conserverà tutti i dati e dovrà fare riferimento a questo servizio per ottenere l'animale o apportare modifiche all'animale domestico, diciamo il nome le modifiche o la modifica dell'indirizzo devono essere effettuate tramite una chiamata API a questo servizio.

Servizio 2 - PetAccessor: questo servizio raccoglie gli animali domestici e esegue controlli di convalida

Servizio 3,4 - Altre chiamate di servizio intermedie

Servizio 5 - Interfaccia utente

Questi sono molto arbitrari ma il punto è semplice. L'interfaccia utente o qualche servizio rivolto all'utente desidera presentare in qualche modo questo oggetto "PET". Deve chiamare tramite un servizio API, che chiama un servizio, che chiama un servizio, ecc. Fino a quando non raggiunge il servizio che raccoglie le informazioni richieste e avvia il relay. Finalmente il servizio di interfaccia utente ha l'oggetto PET da visualizzare.

Questo è abbastanza comune - ma con la nostra mentalità assoluta, abbiamo duplicato l'oggetto PET in ogni servizio. Il principio DRY (non ripeterlo) si applica solo al codice INSIDE di un servizio e non si applica ai servizi ma il punto è ancora lì. Cosa succede se aggiungiamo un campo ... dobbiamo modificare 5 servizi del POJO in ciascuno.

- o- Possiamo fornire una libreria Pet-Objects che contiene alcuni dei pojo dall'API e ogni servizio può importare / dipendere dalla libreria. Non c'è dipendenza dal / dai servizio / i stessi, ma solo dalla biblioteca generale. Mi piace questa idea in modo che ogni servizio abbia lo stesso tipo di oggetto e gli aggiornamenti siano più facili. Ma sono preoccupato per gli Oggetti di Dio.

Quali sono i pro / contro - qual è il miglior design? Che cosa hai fatto per passare i dati tra i servizi per ridurre al minimo la ripetizione delle stesse classi POJO rimanendo anche disaccoppiati?

    
posta Aerith 28.11.2016 - 07:27
fonte

3 risposte

5

What's the best design?

È possibile riutilizzare lo stesso oggetto Pet DTO tra i servizi di back-end (che elaborano la tipica logica aziendale), ma quando si tratta del livello di presentazione (Interfaccia utente), è generalmente un buona pratica per utilizzare un FormBean (un bean diverso con campi aggiunti per la logica di presentazione) in modo che ci sia una netta separazione tra la logica di presentazione e la logica aziendale .

Questo è necessario perché i servizi dovrebbero essere riutilizzabili e un singolo servizio può essere esposto / riutilizzato da più / diversi endpoint (come frontend o potrebbe essere un diverso servizio web, ecc.) e ciascuno di questi gli endpoint potrebbero richiedere campi aggiuntivi che verranno popolati dai rispettivi controller o livelli (come gli adattatori) sopra i servizi.

What have you done to pass data between services to minimize repeating the same POJO classes while also staying de-coupled ?

Se utilizzi un singolo bean tra business e tier web, sei strettamente accoppiato alla logica di presentazione con la logica aziendale che non è una buona pratica e finirai per cambiare i servizi per un requisito nel Frontend (ad esempio, un formato di data diverso da mostrare nell'interfaccia utente). Inoltre, per rendere questo processo di popolamento / copia dei dati attraverso i bean (come DTO a FormBean o Viceversa), puoi usare librerie come Apache BeanUtils.copyProperties() o Dozer per evitare il codice standard .

    
risposta data 28.11.2016 - 07:47
fonte
4

Se il DTO rappresenta la stessa entità aziendale in tutti i microservizi, dovrebbe esserci solo una classe, condivisa tra i servizi. È (quasi) mai corretto avere un codice duplicato per lo stesso oggetto.

    
risposta data 28.11.2016 - 07:42
fonte
0

Il modo in cui ho intenzione di farlo ora è che ogni servizio confeziona solo DTO e li inserisce in Nexus come jar lib. Quando altri servizi ne hanno bisogno, otterranno le loro libbr di DTO come dipendenza in manve / gradle. Se una nuova versione di DTO è rilasciata su un servizio, è valida fino a quando la vecchia versione è supportata allo stesso tempo, quindi non rompere la compatibilità con le versioni precedenti, il controllo delle versioni, ecc. Quindi questa è l'area backend-to-backend. Anche per prevenire la dipendenza circolistica è meglio separare il servizio da dto packaging

Ora guarda il backend-to-front-end e viceversa Non sono d'accordo con i commenti precedenti che l'interfaccia utente come livello di presentazione è diversa. NON È !!! L'interfaccia utente è solo un altro microservizio per me che consuma e produce anche eventi.

Direzione backend-to-frontend Quello che faccio è convertire POJO (dtos) in interfacce e pacchetto Typescript in NPM e caricarli anche in Nexus. Il progetto basato su nodejs dell'interfaccia utente ne consuma e li utilizza. Questo è il modo di servire l'interfaccia utente.

Direzione frontend-backend Per l'interfaccia utente per gli eventi del livello di servizio, converto le interfacce Typescript e le converto in POJO (dtos), pacchetto come jar e caricamento in Nexus (o alcuni repository) in forma di jar da utilizzare dai servizi di back-end.

Questi processi sono facilmente gestiti da processi CI (Travis, Gitlab CI, ecc.)

Qualsiasi commento a questo approccio è stato accolto favorevolmente.

    
risposta data 09.11.2017 - 19:58
fonte

Leggi altre domande sui tag

Sviluppo professionale continuo - l'approccio migliore [duplicato] Repository di organizzazione Github, problemi, più sviluppatori e forking: le migliori pratiche del flusso di lavoro