Dalle intenzioni ai controlli: costruire la prima fitness function

Dalla serie

Obiettivo

Trasformare una proprietà architetturale in una prima fitness function ripetibile, esplicitando criterio, perimetro, misura, condizione di fallimento, responsabilità e conseguenza decisionale; verificarne il comportamento con un caso conforme e una violazione intenzionale.

Prima del controllo viene la proprietà da proteggere

Un principio architetturale resta un desiderio finché non sappiamo quale evidenza potrebbe confermarlo o smentirlo. «Vogliamo un'architettura modulare» è una direzione utile, ma non è ancora verificabile. Il primo passo è trasformarla in una proprietà circoscritta: per esempio, il modulo Ordini non deve dipendere direttamente dalle classi di persistenza di Pagamenti. Qui è utile distinguere due cose. Il Fitness CriterionGlossarioFitness CriterionUna condizione misurabile usata per valutare se un’architettura protegge ancora una caratteristica attesa.Apri la voce completa descrive la condizione che deve essere vera; la Fitness FunctionGlossarioFitness FunctionUn controllo automatizzato o ripetibile che misura nel tempo una caratteristica architetturale.Apri la voce completa è il meccanismo ripetibile che verifica nel tempo se quella condizione continua a essere rispettata. Solo dopo aver chiarito questo passaggio ha senso parlare di strumenti, package o pipeline. Per il nostro esempio, il criterio è zero dipendenze statiche dirette da Ordini a payments.persistence. Il controllo analizzerà il codice applicativo compilato dei moduli interessati e produrrà un elenco dei collegamenti vietati. Definisci fin dall'inizio anche responsabile, conseguenzaGlossarioConseguenzaUn effetto atteso, positivo o negativo, di una decisione.Apri la voce completa decisionale ed esiti possibili: conforme nel perimetro analizzato, violazione e non valutabile. Se i package attesi sono assenti o l'analisi è incompleta, un elenco vuoto non deve diventare un falso verde.

Verifica anche il verificatore

Un controllo che non hai mai visto fallire non è automaticamente affidabile. Potrebbe semplicemente non osservare davvero ciò che pensi. Prepara quindi tre campioni isolati nel codice di testGlossarioTestUna verifica deliberata che produce evidenze su una specifica aspettativa o rischio.Apri la voce completa: una dipendenza consentita, come Ordini verso payments.api, deve passare; una dipendenza vietata verso payments.persistence deve fallire e indicare origine e destinazione; un perimetro assente o non analizzabile deve produrre un esito non valutabile. La violazione intenzionale non serve a testare l'architettura applicativa: serve a dimostrare che il controllo sa riconoscere il rischio dichiarato. Ripeti queste prove quando cambiano package, selettori o configurazione di import. Prima di fidarti del verde, devi aver dimostrato che il controllo è capace di diventare rosso.

Un controllo preciso guadagna chiarezza, ma perde copertura

Una verifica mirata sulle dipendenze statiche può essere adatta a ogni pull request, ma durata e costo vanno misurati sul codice analizzato. Offre un esito interpretabile e rende visibile chi attraversa il confine. In cambio osserva soltanto ciò che il codice importato e lo strumento possono riconoscere: non dimostra isolamento a runtime, correttezza funzionale, assenza di accessi a dati condivisi o modularità complessiva. Anche la soglia zero è una scelta locale, non una legge universale. Nei sistemi esistenti può esserci debito pregresso: invece di dichiararlo improvvisamente tutto bloccante, puoi registrare esplicitamente le eccezioni note e vietare nuovi collegamenti. Il confronto deve riguardare l'identità delle violazioni, non soltanto il loro numero: una nuova violazione non diventa accettabile solo perché ne è scomparsa un'altra. Finché restano eccezioni note, il risultato corretto è «nessuna nuova violazione», non «architettura conforme».

Ordini e Pagamenti in una pipeline enterprise

Immagina una piattaforma retail nella quale team diversi gestiscono Ordini e Pagamenti. Il team Pagamenti vuole poter sostituire la persistenza senza obbligare Ordini a conoscere repository o entità interne. La pipeline analizza a ogni pull request le dipendenze statiche dal codice applicativo compilato nel package com.example.shop.orders verso com.example.shop.payments.persistence, compresi i rispettivi sottopackage. CheckoutService che dipende da payments.api.PaymentService è ammesso rispetto a questa regola; se invece dichiara un campo di tipo payments.persistence.PaymentRepository, il controllo fallisce mostrando il collegamento vietato. Il team Ordini corregge le violazioni introdotte dalle proprie modifiche, mentre il responsabile del confine Pagamenti valuta eventuali richieste di cambiare il criterio. Se una riorganizzazione dei package impedisce l'analisi, la pipeline restituisce non valutabile anziché verde. La riunione di architettura può così discutere un'evidenza concreta: correggere la dipendenza, autorizzare un'eccezione con scadenza oppure ridefinire consapevolmente il confine.

La scheda minima della fitness function

Prima di inserirla nella pipeline, rendi esplicito il contratto del controllo. Questa scheda evita che un test tecnico venga interpretato come una garanzia più ampia di quella realmente offerta. • Intenzione e rischio architetturale da proteggere. • Fitness Criterion: proprietà osservabile e condizione di conformità. • Fitness Function: meccanismo che valuta il criterio. • Perimetro incluso ed esclusioni dichiarate. • Misura prodotta e dettaglio diagnostico atteso. • Esiti conforme, violazione e non valutabile. • Caso positivo, violazione intenzionale e prova di perimetro assente. • Responsabile del controllo e responsabile delle eccezioni. • Frequenza di esecuzione e conseguenza decisionale. • Limiti, debito iniziale e condizioni di revisione.

Per approfondire

Fonti autorevoli per approfondire definizione, integrazione nel ciclo di sviluppo e implementazione tecnica delle fitness function. • Building Evolutionary Architectures — Summary — Sito degli autori di Building Evolutionary Architectures — https://evolutionaryarchitecture.com/precis.html • Fitness function-driven development — Thoughtworks — https://www.thoughtworks.com/insights/articles/fitness-function-driven-development • ArchUnit User Guide — ArchUnit — https://www.archunit.org/userguide/html/000_Index.html

Il controllo viene dopo la scelta

Abbiamo reso verificabile una proprietà. Resta però una domanda più importante: tra tutte le cose che potremmo misurare, quali meritano davvero di essere protette? La prossima uscita parte da qui: scegliere pochi segnali utili prima di riempire dashboard e pipeline.