Microservizio e anti-pattern

I microservizi hanno una connessione molto buona con DDD: in un'architettura sensibile, ogni microservizio gestirà un contesto limitato singolo .

Ogni contesto limitato ha il proprio dominio problematico e quindi il proprio modello. Invece di condividere parti del modello, mantenere il modello ben disaccoppiato e tradurre tra i modelli. Per i microservizi, il limite di contesto corrisponde all'input / output del microservice. Non ottieni nulla creando un microservizio modello o condividendo una DLL modello comune perché non esiste un modello comune. Un cliente potrebbe essere un "account utente" in un contesto di servizio utente e una "carta di credito + indirizzo di fatturazione" in un contesto di servizio di pagamento. Solo perché sono in qualche modo connessi non significa che dovresti rappresentarli attraverso una singola entità in tutti i contesti.

Ma parlando in termini pratici, può avere senso condividere una DLL che contiene i DTO e la loro serializzazione / deserializzazione. Questi DTO non rappresentano il modello di qualsiasi contesto, ma solo la comunicazione tra i tuoi microservizi. Una libreria condivisa fa in modo che la serializzazione sia sempre eseguita correttamente evitando codice ripetuto e consente ai tuoi servizi di utilizzare un'interfaccia strongmente tipizzata. Il rovescio della medaglia è che questo riduce uno dei principali vantaggi dei microservizi: l'agnosticismo tecnologico. Una libreria comune implica anche che le distribuzioni di nuove versioni debbano essere sincronizzate.

Metti i tuoi modelli di trasferimento dati in una libreria condivisa. Versione it

Ogni servizio deve deserializzare i messaggi in arrivo e serializzare quelli in uscita. Quindi, in realtà questi modelli condivisi fungono solo da applicazione contrattuale tra i tuoi servizi e non ha senso aggiungere loro la logica aziendale.

Tuttavia, per ogni microservizio che consumi dovrai scrivere una libreria client (ovvero una libreria che usi per connettersi al servizio come applicata a un modello cliente)

Se questa libreria utilizza gli stessi modelli condivisi utilizzati da tutti i tuoi servizi, ti fa risparmiare un intero livello di mappatura e conversione su ogni singolo componente in cui lo utilizzi.

È un bel po 'di battitura.

Inoltre, il controllo delle versioni ti fornirà avvisi in fase di compilazione se hai la versione del modello sbagliata per la versione client.

I microservizi per loro natura ti spingono verso uno stile di programmazione ADM che non sempre si adatta alla DDD a meno che tu non chiami i servizi stessi come un oggetto Dominio. cioè il CashRegisterService elabora un pagamento piuttosto che il Pagamento è processato

Le librerie condivise generano l'accoppiamento. Questo è tutto. Inoltre modelli canonici .

Dal punto di vista dell'architettura Microservices ( dogmatic ), qualsiasi fattore che possa portare all'accoppiamento (diretto o indiretto) tra i servizi è un fattore indesiderabile, perché è contrario all'indipendenza assoluta di Microservice.

Avere due POJO identici / entità in diversi microservizi non è una violazione di DRY.

Di solito, i microservizi sono sviluppati, gestiti e governati da diversi team. I team si sono formati attorno a capacità e competenze aziendali (non altrimenti).

Di conseguenza, i team non potevano essere assegnati nello stesso dipartimento. Forse, nemmeno nello stesso edificio o città.

Forse i microservizi non condividono nemmeno lo stesso stack tecnologico.

Il problema qui è un problema di decomposizione. Potrebbe interessarti questa lettura .

Sia che ci avviciniamo alla scomposizione da una strategia Contesti o Valore stream , la definizione del modello varia (o si differenzia) in base ai servizi, perché ogni servizio è una business unit di per sé. Ha il suo dominio, le sue regole e la sua logica.

Quindi Cliente , Ordine , Indirizzo , ecc. hanno definizioni diverse, in base all'ambito (servizio) da cui sono guardati.

Ad esempio, dal punto di vista della sicurezza, un cliente non è affatto un cliente. Probabilmente è un account (credenziali, ruoli, profili, ecc.)

Dal punto di vista del reparto spedizioni, un cliente è un nome completo, un indirizzo e, forse, un telefono.

Dal punto di vista del reparto vendite, un cliente è un documento identificativo, una carta di credito e un nome completo.

Va bene avere l'attributo nome e indirizzo in diversi modelli di dati di Microservices. Anche se non sono sincronizzati !!!

Nel mondo reale, quando cambiamo l'indirizzo di fatturazione corrente, le fatture precedenti non cambiano !!! O non dovrebbero! Lo stesso succede con i prezzi. O con i nomi.

Se diversi microservizi devono comunicare cambiamenti sullo stato dei dati, non comunicano direttamente le modifiche, propagano eventi che potrebbero (o non) essere seguiti da altri microservizi.

In Microservices, SRP e DRY operano in livelli più alti di astrazione (strategie aziendali e aziendali) rispetto a quelli con cui abbiamo più familiarità (classi e componenti).

Tornando alla domanda principale, la mia risposta è cercare di evitare le librerie condivise. Le principali fonti di accoppiamento utilizzano comunicazioni sincrone tra processi e librerie condivise. Quindi, vi incoraggio ad approfondire: la decomposizione dei microservizi e le strategie di comunicazione tra processi di microservizi.