Accounting Hub: microservizi generici invece di un servizio per prodotto

01Il sintomo: il copia-incolla istituzionalizzato

In un hub contabile ogni nuovo prodotto portava con sé il suo servizio: stessa struttura, stessi passaggi, differenze nei dettagli. Dopo qualche anno il catalogo è un insieme di varianti quasi identiche, ognuna con la sua dose di correzioni applicate solo lì.

Il problema non è lo spazio su disco, è che una correzione va replicata dieci volte e qualcuno se ne dimentica sempre. La domanda giusta non è «quanti servizi abbiamo», è «quante volte dobbiamo cambiare la stessa cosa in punti diversi».

02Il modello target: pochi ruoli, chiari

Il modello su cui ho lavorato separa quattro responsabilità. Un BFF come unico punto di ingresso per la GUI, che non contiene logica di dominio. Un orchestratore che governa l'ordine degli step, le policy di errore e i ritentativi. Un wizard stateless che esegue step standard — READ, VALIDATE, MAP, WRITE — caricando la configurazione dal database. E un repository unico dove vivono definizioni di processo, parametri e query, versionabili come codice.

La regola che tiene in piedi tutto: il wizard non riceve SQL arbitrario dalla GUI. Riceve l'identificativo del processo e va a leggersi la configurazione. Se salti questa regola hai costruito una console di amministrazione remota, non un'architettura.

GUI ──> BFF (solo entry point)
        └──> Orchestratore (ordine step, retry, policy errore)
               └──> Wizard stateless
                      READ ──> VALIDATE ──> MAP ──> WRITE
                      ^ configurazione e query dal repository unico

03Tracciabilità: non un extra, il motivo

In un dominio soggetto a controlli come SOX la domanda di un auditor è sempre la stessa: chi ha fatto cosa, con quale configurazione, con quale esito. Se la risposta richiede di leggere i log applicativi a mano, il sistema è già in difficoltà.

Con step standard la registrazione diventa strutturale: ogni run e ogni step hanno un identificativo, un input, un esito e una durata. Si può rieseguire un singolo step senza ripartire da zero, e questo è utile in produzione alle sette del mattino molto più che in una presentazione.

Sul fronte qualità: quality gate su SonarQube, analisi statica e dinamica con Veracode, credenziali centralizzate in un vault invece che nei file di configurazione. Sono tre cose noiose che diventano interessanti il giorno dell'audit.

04Cosa cambia e cosa costa

Il risultato che si può raccontare al Business: un nuovo prodotto si aggiunge con nuovi workflow e nuove query, non con un nuovo servizio da mantenere per sempre. Il tempo di rilascio scende perché scende la quantità di codice nuovo da scrivere e da testare.

Il costo va detto: un modello generico concentra il rischio. Un errore nel wizard riguarda tutti i prodotti, quindi servono test seri sul motore e una disciplina ferrea sulle modifiche. È un compromesso consapevole: meno superficie da mantenere, più attenzione dove tutti passano.