Un DSL in YAML per non riscrivere codice a ogni regola di business
Quando ogni variazione richiesta dal Business diventa una modifica al codice, il problema non è il Business: è l'architettura. Come ho spostato la logica dal codice alla configurazione.
Indice
- 01Il sintomo
- 02La scelta: dichiarare invece di programmare
- 03Le due regole che tengono in piedi il modello
- 04Cosa cambia davvero
01Il sintomo
In un hub contabile i processi erano descritti in XML rigidi e poco leggibili, con la logica dispersa e in parte scritta a mano nel codice. Ogni richiesta del Business — una nuova regola, un campo in più, un flusso alternativo — richiedeva tempi di sviluppo e test sproporzionati rispetto al valore della modifica.
Il vero costo non era la singola riga: era la dipendenza da chi conosceva quella parte da anni. Un'architettura che richiede memoria storica non è un'architettura, è un debito.
02La scelta: dichiarare invece di programmare
Ho lavorato su un modello in cui il processo viene dichiarato in un file YAML e il motore lo esegue. Ogni tag del descrittore è mappato su un componente Java dedicato: il file dice cosa fare e con quali parametri, il componente sa come farlo sulla JVM.
Gli step sono deliberatamente pochi e standard — leggi, valida, trasforma, scrivi — perché un DSL con cento primitive è solo un linguaggio di programmazione peggiore di Java.
flow: quote-evaluation
steps:
- tag: fetch.customer # -> FetchCustomerComponent.java
params: { id: ${input.customerId} }
- tag: rules.apply # -> RulesApplyComponent.java
params: { ruleset: retail-v3 }
onError: { policy: retry, attempts: 3 }
- tag: persist.result # -> PersistResultComponent.java03Le due regole che tengono in piedi il modello
Prima regola: il motore non riceve mai istruzioni arbitrarie dall'esterno. La GUI non manda SQL, manda l'identificativo del processo; il motore carica la configurazione dal repository. Altrimenti hai costruito una console di amministrazione remota e l'hai chiamata architettura.
Seconda regola: definizioni, parametri e query vivono in un repository unico e versionabile. Se non puoi fare la diff di una modifica e tornare indietro, non hai configurazione: hai un file di testo in produzione.
04Cosa cambia davvero
Lo sviluppo si sposta sulla configurazione e il motore resta stabile: un nuovo prodotto si aggiunge con nuovi workflow e nuove query, non con un fork del codice. La tracciabilità migliora come effetto collaterale, perché ogni esecuzione e ogni step sono registrati e ispezionabili — utile quando il dominio è soggetto a controlli come SOX.
Il limite va detto: un DSL è un prodotto interno. Va documentato, versionato e difeso dalla tentazione di aggiungere un tag ogni volta che qualcosa non rientra nel modello.
Hai un problema simile sul tuo sistema?
Parliamone