Costruire e validare una prima fitness function su un confine modulare

Tipo

Pratica

DA UN'INTENZIONE A UNA PROPRIETÀ VERIFICABILE. «Vogliamo un'architettura modulare» esprime una direzione, non una condizione verificabile. Una fitness function architetturale valuta oggettivamente una o più caratteristiche dell'architettura; può usare test, metriche o altri meccanismi di verifica. Conta la relazione con la proprietà da proteggere, non il nome dello strumento [1]. Il criterio descrive la condizione accettabile; la fitness function è il meccanismo che la valuta nel tempo. Per cominciare, scegli un rischio riconoscibile e una verifica con esito interpretabile. Qui usiamo dipendenze statiche per illustrare il ciclo completo senza soglie di prestazione arbitrarie o un ambiente distribuito: è una scelta didattica, non una priorità universale. ESEMPIO: ORDINI E PAGAMENTI. In una piattaforma inventata, il team vuole cambiare la persistenza di Pagamenti senza costringere Ordini a conoscere quelle classi. I package applicativi sono com.example.shop.orders, com.example.shop.payments.api e com.example.shop.payments.persistence, inclusi i rispettivi sottopackage. La proprietà protetta è l'assenza di dipendenze statiche dirette dal codice applicativo di Ordini alle classi di persistenza di Pagamenti. Il criterio richiede zero dipendenze di quel tipo: lo zero esprime il divieto scelto dal team, non una soglia universale di buona architettura. Il controllo importa il codice applicativo compilato dei moduli interessati, verifica che i package attesi siano presenti e valuta le dipendenze dal primo insieme al secondo. Test e campioni didattici restano separati dal perimetro applicativo. Ordini.CheckoutService → Pagamenti.api.PaymentService è consentita rispetto a questa regola; Ordini.CheckoutService → Pagamenti.persistence.PaymentRepository è una violazione. L'output deve identificare origine e destinazione, non limitarsi a un semaforo rosso. ALGORITMO CONCETTUALE, NON CODICE ESEGUIBILE. Carica le classi applicative; verifica completamento dell'analisi e presenza dei package attesi; se il perimetro è assente, incompleto o non analizzabile restituisci NON VALUTABILE; altrimenti raccogli le dipendenze statiche dirette da orders a payments.persistence; se non ne esistono restituisci CONFORME ALLA REGOLA NEL PERIMETRO ANALIZZATO, altrimenti VIOLAZIONE con l'elenco dei collegamenti vietati. Un'implementazione Java può usare ArchUnit, che analizza bytecode e supporta regole sulle dipendenze tra package [3]. Lo strumento è un esempio, non un requisito del metodo. La regola vieta una dipendenza precisa: non dimostra che ogni interazione con Pagamenti passi dalla sua API pubblica. VERIFICARE IL VERIFICATORE. Prepara tre prove in codice di test isolato: una dipendenza consentita deve passare; una vietata deve fallire indicando il collegamento introdotto; package assenti o analisi fallita non devono risultare conformi. La violazione intenzionale valida il controllo e non va inserita nel codice applicativo distribuito. Un elenco vuoto di violazioni ha valore solo se il perimetro è quello atteso. ArchUnit documenta una protezione contro regole che non selezionano classi: va verificata insieme alla configurazione di import, non scambiata per prova automatica della completezza dell'analisi [3]. Dopo una rinomina, verifica anche selettori e campioni. Nessun dato e nessuna violazione sono risultati diversi. INSERIMENTO NEL LAVORO QUOTIDIANO. Nello scenario proposto, esegui il controllo a ogni pull request. Il team Ordini risolve le violazioni nelle proprie modifiche; il responsabile del confine Pagamenti valuta le richieste di cambiare il criterio. Un fallimento richiede correzione o decisione esplicita, non disattivazione silenziosa del test. Un esito non valutabile impedisce di usare il controllo come evidenza positiva e richiede di ripristinare l'analisi. Integrare verifiche legate agli obiettivi architetturali nello sviluppo è coerente con il fitness function-driven development [2]. Su sistemi esistenti, esegui prima una rilevazione iniziale e rendi visibili le violazioni note. Una possibile adozione graduale registra l'elenco esatto delle violazioni temporaneamente tollerate e vieta quelle nuove, con responsabile e revisione delle eccezioni. Non basta impedire che aumenti il conteggio: una nuova violazione potrebbe sostituirne una vecchia lasciando il totale invariato. Descrivi l'esito come «nessuna nuova violazione», non come piena conformità. Non aggiornare automaticamente le eccezioni per far tornare verde la pipeline. LIMITI E SCHEDA MINIMA. Questo controllo osserva solo le dipendenze statiche dirette riconoscibili nel codice importato. Non dimostra correttezza funzionale, assenza di accessi a dati condivisi, isolamento a runtime, assenza di collegamenti dinamici o modularità complessiva. Un risultato verde protegge una proprietà delimitata, non certifica l'intera architettura. La scheda minima comprende: intenzione e rischio; proprietà e criterio; perimetro; misura; esiti conforme, violazione e non valutabile; prove positive e negative; responsabile; frequenza; azione conseguente; limiti e condizioni di revisione. Rivedila quando cambiano il confine, il codice analizzato o il valore del controllo. La governance di un insieme di verifiche è il passo successivo, già trattato in KA-094 e nella Issue sul portfolio. FONTI PRIMARIE. [1] Building Evolutionary Architectures, Summary, sito degli autori: https://evolutionaryarchitecture.com/precis.html (definizione e ambito). [2] Thoughtworks, Fitness function-driven development: https://www.thoughtworks.com/insights/articles/fitness-function-driven-development (obiettivi architetturali e ciclo di sviluppo). [3] ArchUnit User Guide, sezioni Package Dependency Checks, Import e Fail Rules on Empty Should: https://www.archunit.org/userguide/html/000_Index.html (meccanismo tecnico e perimetro importato). Il caso Ordini/Pagamenti, la scheda e la sequenza di prove sono una proposta didattica originale: non descrivono un'implementazione reale o un test eseguito su Architecture Coffee.