È una buona idea condividere i repository su microservices in Spring Boot Application?

I vehemently opposed

Vehemence fa semplicemente smettere di ascoltare gli altri. Allo stesso tempo, è un segno che stiamo (forse) limitando la nostra percezione del problema e della soluzione. Detto questo, non essere dogmatico. Sii pragmatico.

Although shared entities sound harmless to me, I opposed the idea of having shared repositories

Condividere i repository potrebbe essere una buona idea, in generale nelle prime fasi del progetto. Se abbiamo solo un database e un solo modello di dati relazionali, perché no?

1. Viole S di SOLID. Un microservizio dovrebbe vedere solo & operare sui dati che possiede.

   Non viola SOLID in alcun modo dannoso (ancora). L'unica fonte di dati per MS è l'ideale. L'architettura MS è all'avanguardia, ma non è una regola scritta su pietra . Martin Fowler non apparirà e mangerà la tua anima se non lo fai in quel modo.

   Prendere decisioni su qualcun altro è una decisione mediocre. Quando leggiamo articoli su internet, ricordiamo che spesso non sappiamo nulla (o molto poco) dei requisiti che hanno portato gli autori a fare ciò che hanno fatto. Ma il più importante è che citano a malapena i costi delle loro decisioni.

   Separeremo le origini dei dati quando troveremo una buona ragione per farlo. Nelle architetture MS, la maggior parte delle ragioni sono strategiche e raramente tecniche. Le architetture MS sono state promosse (principalmente) da aziende con sistemi monolitici molto grandi. Queste aziende avevano bisogno di un modo per articolare SDLC diversi in modo da ridurre il time-to-market, parallelizzare l'SDLC, acquisire la capacità di implementare nuove funzionalità e riprenderle in qualsiasi momento, ecc.

   Considera anche che, forse, non sei completamente consapevole del contesto in cui il progetto è in fase di sviluppo. Forse ti manca la visione dell'azienda, i suoi limiti e risorse a portata di mano.

   Inizia poco. Va bene per adattare l'architettura alle esigenze e alle risorse immediate. E evolvilo man mano che i bisogni arrivano.

2. Gli sviluppatori sotto pressione useranno direttamente questi repository in altri servizi per modificare i dati di proprietà di altri microservizi.

   Non necessariamente, possiamo isolare i repository in diverse librerie. Diciamo che comprimiamo i repository come librerie condivise in modo che ogni servizio includa solo quelli di cui ha bisogno.

   Inoltre, facciamo in modo che i nostri servizi si connettano all'origine dati con profili diversi, ognuno dei quali con diverse sovvenzioni, ruoli o vincoli. Ad esempio, RDBMS è dotato di controllo di accesso immediato. Usalo.

3. Porta a duplicare il codice e, eventualmente, le convalide perse

   Porta al riutilizzo del codice, e questo potrebbe essere positivo per tutti voi nelle prime fasi dello sviluppo. Per quanto riguarda il codice mancante, dovremo contestualizzarlo. Ad esempio, alcune convalide potrebbero avere senso in alcuni servizi e nessuna in altre.

   Ricorda che un "modello" potrebbe essere interpretato in modo diverso da servizi diversi. Ad esempio, per "CustomerService" i clienti sono un nome, un cognome, due indirizzi, età, sesso, ecc. Per i clienti "ShippingService" si intendono un nome e 2 indirizzi. Il primo potrebbe aver bisogno di convalide di età, l'ultima probabilmente no.

4. Potrebbe portare a concorrenza e amp; problemi di dati su larga scala.

   Oppure no. L'ottimizzazione prematura è il seme del male. Non sovradimensionare il sistema fino a quando non ottieni prove per farlo.

   La concorrenza potrebbe essere un problema se pochi servizi sovraccaricano l'origine dati in modo che il resto del sistema ne subisca le conseguenze. Questo è un buon argomento per separare l'origine dei dati. Per quanto riguarda la condizione di gara sui dati, accade anche nelle architetture MS disaccoppiate, dove è ancora più difficile da risolvere.

Are my concerns wrong?

Hai ragione teoricamente, tuttavia, non sei abbastanza pratico. Non sei pagato per implementare architetture allo stato dell'arte, sei pagato per risolvere i problemi con tutto ciò che hai a portata di mano. L'eccellenza potrebbe venire dopo (se mai arriverà).

did I miss any possible negative impacts (present/ future)?

Sì, ma hanno importanza solo se contano.

Le librerie condivise significano che per sfruttare il riutilizzo del codice, altri servizi devono essere implementati con lo stesso linguaggio di programmazione. Questo è alquanto contrario alla filosofia MS ¹ .

Il riutilizzo del codice accoppia anche gli SDLC poiché le modifiche nel codice sorgente comune potrebbero penalizzare la strategia di consegna, quindi il time-to-market.

Riassumendo

Sii pragmatico e aperto. Sii critico con tutto ciò che leggi su Internet. Ricorda sempre che il tuo progetto impone il cosa, quando e come dovrebbe essere implementato.

Realtà vs percezione

La realtà è tutta una questione di percezione. Puoi fornire la "percezione" di avere diverse fonti di dati quando c'è solo un "reale". Rendilo reale quando c'è un vero motivo per farlo.

^{1 - L'architettura MS è interamente basata sulla libertà di implementazione e resilienza}

Prima di tutto i tuoi microservizi dovrebbero operare sui propri DB ... ora anche se non è così, è generalmente una buona idea architettare la tua applicazione in un modo che permetta questo o almeno non faccia è ovvio che il db è condiviso.

Suggerirei vivamente di mantenere i repository utili per un singolo SM il più possibile e di non consentire la condivisione di repository tra gli SM. In questo modo rimane molto chiaro chi possiede cosa all'interno del sistema e mantiene l'idea di un database condiviso lontano da qualsiasi altro livello delle tue applicazioni.

Questa libreria condivisa potrebbe esistere per un po 'di tempo perché sei nel mezzo di una migrazione, ma hai bisogno di un piano per svanire questa libreria il prima possibile.

L'utilizzo di micro servizi con una libreria condivisa è considerato un cattivo odore in alcuni casi , ma comprensibile se stai cercando di rompere un monolite applicazione in piccoli pezzi (servizi). Penso che possiamo considerare la tua applicazione desktop come un'applicazione monolite.

Gestire una libreria condivisa che contiene entità e repository mi sembra una cattiva idea. Avrai bisogno di gestire molti cambiamenti su questo tizio e, probabilmente, a volte dovrai forzare ad aggiornare la versione di queste librerie condivise in tutti i micro servizi. Ma come ho detto, se questa situazione è temporanea finché non identificherai i proprietari dei servizi giusti di ciascun database e rimuovi questa libreria condivisa in futuro, per me è una soluzione temporanea accettabile.

Ricorda: in generale, i micro servizi sono una buona idea quando sono molto indipendenti. Pensa se hai veramente bisogno di questi micro servizi che hai creato e se un monolite, prima di interromperti sui micro servizi, non è una scelta migliore finché non capisci di quali servizi micro hai bisogno.