Scegliere microservizi in base alle modifiche indipendenti

Quale modifica deve poter avvenire in autonomia?

Distribuire un’applicazione tra servizi non crea da solo evoluzione indipendente. Se le stesse persone devono modificare e rilasciare insieme tutti i servizi per ogni regola di prezzo, il coordinamento rimane. Si aggiungono chiamate di rete e attività operative.

Microsoft indica rilascio indipendente e responsabilità dei dati tra le caratteristiche importanti. Proponiamo quindi di partire da una modifica concreta: quale ambito aziendale deve poterla sostenere senza adattare contemporaneamente gli altri?

Esempio: preventivi e ordini restano insieme per ora

Questo prodotto e il suo funzionamento sono inventati. Un team gestisce preventivi, ordini e rapporti. Le regole di prezzo cambiano insieme in preventivi e ordini. I formati dei rapporti hanno esigenze diverse.

In questo piano l’applicazione resta inizialmente un monolite modulare: confini interni, rilascio comune. Spring Modulith illustra la distinzione tra interfaccia pubblica del modulo e implementazione interna. Descriverla è utile anche senza scegliere questo strumento specifico.

Includa la gestione operativa nella decisione

Un servizio separato di rapportistica dovrebbe gestire guasti della propria fonte dati. Qualcuno dovrebbe rispondere di rilascio, monitoraggio e analisi degli incidenti. Servono anche regole per la convivenza tra vecchie e nuove versioni dell’interfaccia durante una transizione. Un processo separato da solo non basta.

Registri il motivo di una separazione futura, per esempio necessità reale di rilascio indipendente o carico da trattare diversamente. Rivaluti accoppiamento, accesso ai dati e impegno operativo. Anche moduli rilasciati insieme possono avere una struttura chiara. Un servizio ben delimitato può essere giustificato prima di dividere il resto. Il numero di servizi non misura la qualità di questa decisione.

Fonti

• Microsoft: Microservices architecture

• Spring Modulith: Fundamentals