Modi per condividere DTO su microservizi?

Il mio consiglio? Non condividere questi DTO tra le applicazioni in qualsiasi tipo di libreria. O almeno non farlo adesso.

Lo so, sembra molto contro-intuitivo. Stai duplicando il codice, giusto? Ma questa non è una regola aziendale, quindi puoi essere più flessibile.

Il servizio che invia il DTO deve essere rigido nel suo contratto di messaggio, come un'API Rest. Il servizio non può modificare il DTO in un modo che potrebbe interrompere gli altri servizi che stanno già consumando le informazioni dal DTO.

Quando viene aggiunto un nuovo campo DTO, si aggiornano solo gli altri servizi che consumano questo DTO se hanno bisogno del nuovo campo. Altrimenti, dimenticalo. Usando JSON come tipo di contenuto hai la flessibilità di creare e inviare nuovi attributi senza interrompere il codice dei servizi che non mappano questi nuovi campi sulle sue versioni effettive di DTO.

Tuttavia, se questa situazione ti dà davvero fastidio, puoi seguire la Regola del Tre :

There are two "Rules of Three" in reuse: (a) It is three times as difficult to build reusable components as single use components, and (b) a reusable component should be tried out in three different applications before it will be sufficiently general to accept into a reuse library.

Quindi, prova ad aspettare un po 'prima di condividere questo DTO tra i servizi.

Inoltre la risposta di Dherik. Quando si tratta di Microservices, gli sviluppatori spesso dimenticano una caratteristica importante di questa architettura. I servizi e i rispettivi SDLC sono (o dovrebbero essere) totalmente indipendenti ^* .

Detto questo, potrebbero essere coinvolti diversi team di sviluppo. Ciascuno dei quali è responsabile di uno o più servizi. Queste squadre potrebbero non essere nello stesso ufficio, città o paese.

Poiché ogni servizio ha i suoi requisiti e le sue esigenze, la attività non è l'unica differenza tra loro. Anche lo stack tecnologico potrebbe essere diverso. Quindi, imporre DTO implementati in una tecnologia specifica potrebbe diventare controproducente (dal punto di vista dell'architettura) .

Quando pensiamo a questo, (non riusare il codice ), abbiamo paura di schernire la bestia ASCIUTTA . Ma questo non è necessariamente vero.

Supponiamo che la nostra organizzazione abbia diversi reparti. Servizio assistenza clienti , Vendite e Spedizione . Supponiamo che ognuno di loro pubblichi uno o più servizi, ciascuno dei quali, sia correlato alle rispettive capacità aziendali .

A causa della sua lingua del dominio , il servizio clienti ha richiesto di modellare la propria attività customer-centric . Il concetto di Cliente è importante, quindi è modellato in dettaglio. Ad esempio, clienti sono modellati come persone con nome , cognome , età , email , telefono , ecc.

Ora dì, Vendite e Spedizione rilascia anche i loro servizi. Entrambi i dipartimenti hanno modellato la propria attività in base alla propria lingua di dominio. In queste lingue appare anche il concetto cliente . Ma con una differenza notevole. Per questi nuovi servizi, clienti non sono più il concetto centrale. Mentre, per Vendite , i clienti sono un numero documento e una carta di credito , per Spedizione , i clienti sono un < em> nome completo e due indirizzi .

Se dovessimo imporre un modello canonico a Spedizione e Vendite , non imporremo solo l'accoppiamento, sposteremo anche la complessità non necessaria dal servizio al servizio e replicheremo i dati più volte su tutta l'architettura.

Link correlati

• Microservices & Modello canonico
• Evita un modello di dati canonico

^{* Ecco dove sono i punti di forza di questa architettura}

I'm trying to design every service to be as independent as possible

Dovresti pubblicare eventi . Gli eventi sono determinati tipi di messaggi che rappresentano un fatto solido su qualcosa che è accaduto in un particolare momento.

Ogni servizio dovrebbe avere una responsabilità ben definita e dovrebbe avere la responsabilità di pubblicare gli eventi relativi a tale responsabilità.

Inoltre, vuoi che i tuoi eventi siano eventi legati al business, non eventi tecnici. Per esempio. preferisci OrderCancelled event a OrderUpdated con status: "CANCELLED" .

In questo modo, quando un servizio deve reagire a un ordine annullato, ha solo bisogno di ascoltare quel particolare tipo di messaggio, che sta trasportando solo i dati rilevanti per quell'evento. Per esempio. un OrderCancelled probabilmente ha solo bisogno di un order_id . Qualunque servizio che debba reagire a questo ha già memorizzato tutto ciò che è necessario sapere sull'ordine nel proprio data store.

Ma se il servizio aveva solo OrderUpdated di eventi da ascoltare, allora avrebbe dovuto interpretare il flusso degli eventi, e ora dipendeva dall'ordine di consegna per concludere correttamente quando un ordine è stato cancellato.

Nel tuo caso, tuttavia, poiché stai pubblicando i dati dei sensori, potrebbe avere senso avere un servizio, ascoltare gli eventi e pubblicare un nuovo flusso di "eventi aziendali", ad es. TemperatureThresholdExceeded , TemperatureStabilised .

E stai attento a creare troppi microservizi. I microservizi possono essere un ottimo modo per incapsulare la complessità, ma se non si individuano limiti di servizio adeguati, la complessità è nell'integrazione del servizio. E questo è un incubo da mantenere.

È meglio avere troppo pochi, servizi troppo grandi, piuttosto che avere troppi servizi troppo piccoli.