Costruire e validare una prima fitness function su un confine modulare

Dall'intenzione alla proprietà verificabile

«Vogliamo un'architettura modulare» è un'intenzione, non una condizione verificabile. La fitness function valuta nel tempo una proprietà architetturale con test, metriche o altri meccanismi; il criterio descrive la condizione accettabile, mentre il controllo la verifica. Partiamo da un rischio concreto e da un esito interpretabile: evitare dipendenze statiche dirette dal codice Ordini verso la persistenza di Pagamenti.

Un confine modulare: Ordini e Pagamenti

Definire perimetro, misura ed esiti

1. Carica il codice applicativo compilato dei moduli interessati ed escludi i campioni didattici e i test.
2. Verifica che il perimetro atteso sia presente e l'analisi sia completa.
3. Se il perimetro è assente o incompleto, restituisci NON VALUTABILE.
4. Raccogli le dipendenze statiche dirette da orders a payments.persistence.
5. Se sono assenti restituisci CONFORME ALLA REGOLA NEL PERIMETRO ANALIZZATO; altrimenti VIOLAZIONE con origine e destinazione.

È un algoritmo concettuale, non codice eseguibile. ArchUnit è un possibile strumento Java per verificare dipendenze sul bytecode, 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

• Una dipendenza consentita passa?
• Una dipendenza vietata fallisce e identifica origine e destinazione?
• Package assenti o analisi fallita restituiscono NON VALUTABILE, anziché un verde ingannevole?
• Dopo rinomine o cambi di build sono stati verificati selettori, import e campioni?

Introduci la violazione intenzionale soltanto in test isolati, non nel codice distribuito. ArchUnit documenta controlli contro regole che non selezionano classi; verifica comunque anche la configurazione dell'import. «Nessun dato» e «nessuna violazione» sono esiti diversi.

Inserire il controllo nella delivery

Nello scenario proposto il controllo gira a ogni pull request. Il team Ordini corregge le violazioni introdotte dalle sue modifiche; il responsabile del confine Pagamenti valuta i cambiamenti al criterio. Un fallimento richiede una correzione o una decisione esplicita; un esito non valutabile non può essere usato come evidenza positiva.

Su sistemi esistenti rileva prima il debito noto. Un'adozione graduale può registrare l'elenco esatto delle violazioni temporaneamente ammesse e vietare quelle nuove, con owner e revisione delle eccezioni. Non basta controllare il conteggio: una violazione nuova potrebbe sostituirne una vecchia senza cambiarne il totale. Non aggiornare automaticamente le eccezioni per far tornare verde la pipeline.

Limiti e scheda operativa

Il controllo osserva soltanto dipendenze statiche dirette riconoscibili nel perimetro importato. Non dimostra correttezza funzionale, assenza di dati condivisi o collegamenti dinamici, isolamento a runtime o modularità complessiva. Un esito verde tutela una proprietà delimitata, non l'intera architettura.

• Intenzione e rischio sono espliciti?
• Proprietà, criterio, perimetro e misura sono definiti?
• Gli esiti conforme, violazione e non valutabile sono distinti?
• Le prove positive, negative e di perimetro sono ripetibili?
• Owner, frequenza, azione conseguente e limiti sono documentati?
• Sono chiare le condizioni che richiedono revisione del controllo?

Il passo successivo è governare il portfolio delle verifiche, approfondito in KA-094.

Fonti e perimetro dell'esempio

• Building Evolutionary Architectures, sintesi degli autori: https://evolutionaryarchitecture.com/precis.html
• Thoughtworks, Fitness function-driven development: https://www.thoughtworks.com/insights/articles/fitness-function-driven-development
• ArchUnit User Guide, controlli sulle dipendenze, import e regole senza classi selezionate: https://www.archunit.org/userguide/html/000_Index.html

Il caso Ordini/Pagamenti, la scheda e le prove sono esempi didattici originali, non un'implementazione o un test realmente eseguiti su Architecture Coffee.