Disaccoppiare prima che le dipendenze rallentino.

Chiarire responsabilità e titolarità dei dati prima della suddivisione tecnica

Un servizio necessita di un compito di business comprensibile. Analizziamo processi, proprietà dei dati e dipendenze nelle modifiche prima di scorporare i componenti. Se più servizi condividono le stesse tabelle e devono sempre essere rilasciati insieme, spesso si crea solo una dipendenza distribuita senza il beneficio desiderato.

Distinguiamo le richieste sincrone dalle fasi di processo asincrone. Per i processi di business che coinvolgono più servizi, gli stati intermedi e la compensazione vengono modellati in modo esplicito. Una prenotazione annullata, per esempio, è un'azione di business e non un rollback tecnico qualsiasi su tutti i database.

Rendere gli errori distribuiti visibili e gestibili

Con più servizi nascono ulteriori percorsi di rete e possibili guasti parziali. Pianifichiamo timeout, limiti e nuovi tentativi in modo che un servizio lento non blocchi l'intera applicazione. Un nuovo tentativo automatico presuppone che un'azione non venga eseguita più volte in modo involontario.

L'introduzione avviene in un ambito circoscritto con un beneficio misurabile. Standard comuni per log, trace, distribuzione e reperibilità evitano che ogni servizio si inventi proprie regole operative. Se il beneficio previsto non giustifica lo sforzo, un'applicazione modulare con una struttura chiara può restare la soluzione più adatta.