Lo dico una volta per tutte: I microservice sono una cagata pazzesca.

L’aspetto a mio personalissimo modo di vedere problematico e che porta troppo spesso ad errori di design madornali è che la teoria dei microservice confonde:

• gli aspetti di design (SOA)
• con gli aspetti di deploy
• con gli aspetti infrastrutturali legati al come garantisco alta scalabilità e alta affidabilità
• infine siccome non era abbastanza detta anche un assioma sulla dimensione.

I microservice, se interpretati con il minestrone li sopra, sono una cagata pazzesca.

La “dimensione”, che poi mi piacerebbe capire quale unità di misura vi aspettate di usare, è l’ultimo dei vostri problemi. Il primo passaggio è comprendere il dominio: decomposizione del dominio (ad esempio tramite Context Mapping e Bounded Context), identificando i BC, da li module e submodule arrivando ad un concetto molto simile ai servizi di SOA.

Identificati i moduli diventa abbastanza semplice (si fa per dire) definire gli aggregati, gli aggregati non hanno dipendenze dirette tra loro (o meglio non dovrebbero), quindi un aggregato può essere visto come un componente nel mondo SOA, per il quale i componenti sono autonomi.

Attenzione che autonomi non ha ancora nulla a che spartire con il deploy.

Identificati i componenti la macro architettura è li che ci guarda, ora non ci resta che disegnare i messaggi (secondo SOA, quindi non ancora messaggi su una coda, o chiamate HTTP, o quello-che-vi-attizza-come-tecnologia) stiamo parlando di payload, come lo trasportiamo non è ancora un problema, ci interessa capire:

• cosa trasportiamo
• da dove a dove
• quali dipendenze il carico ci impone

A questo punto l’architettura è definita, ora potete ricominciare da capo e aggiungere i vincoli di deploy, tecnologici, tecnici, di budget, etc…

Sono tutte cose ovviamente importantissime, ma se finiscono con l’avere un impatto sulle scelte architetturali imponendoci dei compromessi dobbiamo sapere che abbiamo fatto dei compromessi, partire ciecamente con dei compromessi, soprattutto se dettati da requisiti non funzionali, ci porta a disegnare un qualcosa che è castrato in partenza e che non mira a risolvere il problema di business ma mira a risolvere prima quello tecnologico portando quasi certamente a più danni che benefici perché a questo punto è il requisito di business che ne soffre.