Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Processo di ADR
Un record della decisione sull'architetttura (ADR, architectural decision record) è un documento che descrive una scelta fatta dal team su un aspetto significativo dell'architettura software che intende creare. Ogni ADR descrive la decisione architettonica, il suo contesto e le sue conseguenze. Gli ADR presentano degli stati e quindi seguono un ciclo di vita. Per un esempio di ADR, consulta l'appendice.
Il processo di ADR produce una raccolta di record delle decisioni sull'architettura. Questa raccolta forma il log delle decisioni. Il log delle decisioni fornisce il contesto del progetto e informazioni dettagliate sull'implementazione e sulla progettazione. I membri del progetto sfogliano i titoli di ogni ADR per avere una panoramica del contesto del progetto. Leggono gli ADR per approfondire le implementazioni del progetto e le scelte di progettazione.
Quando il team accetta un ADR, questo diventa non modificabile. Se in base a nuove informazioni è richiesta una decisione diversa, il team propone un nuovo ADR. Quando il team accetta il nuovo ADR, questo sostituisce l'ADR precedente.
Ambito del processo di ADR
I membri del progetto devono creare un ADR per ogni decisione significativa dal punto di vista architettonico che influisca sul progetto o sul prodotto software, incluse le seguenti (Richards e Ford 2020):
-
Struttura (ad esempio, pattern come i microservizi)
-
Requisiti non funzionali (sicurezza, alta disponibilità e tolleranza agli errori)
-
Dipendenze (accoppiamento di componenti)
-
Interfacce (API e contratti pubblicati)
-
Tecniche di costruzione (librerie, framework, strumenti e processi)
I requisiti funzionali e non funzionali sono gli input più comuni del processo di ADR.
Contenuti dell'ADR
Quando il team identifica la necessità di un ADR, un membro del team inizia a scriverlo sulla base di un modello a livello di progetto. (Consulta l'Organizzazione ADR GitHub
Processo di adozione dell'ADR
Ogni membro del team può creare un ADR, ma il team deve stabilire una definizione di proprietà per l'ADR. Ogni autore proprietario di un ADR dovrebbe mantenere e comunicare attivamente i contenuti dell'ADR. Per spiegare in modo chiaro questa proprietà, nelle seguenti sezioni questa guida si riferisce agli autori dell'ADR come a Proprietari dell'ADR. Gli altri membri del team possono sempre contribuire a un ADR. Se il contenuto di un ADR cambia prima che il team lo accetti, il proprietario deve approvare tali modifiche.
Il seguente diagramma illustra il processo di creazione, proprietà e adozione dell'ADR.
Dopo che il team ha identificato una decisione architettonica e il suo proprietario, il proprietario dell'ADR fornisce l'ADR nello stato Proposto all'inizio del processo. Gli ADR nello stato Proposto sono pronti per la revisione.
Il proprietario dell'ADR avvia quindi il processo di revisione dell'ADR. L'obiettivo del processo di revisione dell'ADR è decidere se il team lo accetta, se stabilisce che necessita di una rielaborazione o se lo rifiuta. Il team del progetto, incluso il proprietario, esamina l'ADR. La riunione di revisione dovrebbe iniziare con un intervallo di tempo dedicato alla lettura dell'ADR. In media, dovrebbero essere sufficienti dai 10 ai 15 minuti. Durante questo periodo, ogni membro del team legge il documento e aggiunge commenti e domande per segnalare gli argomenti poco chiari. Dopo la fase di revisione, il proprietario dell'ADR legge ad alta voce e discute ogni commento con il team.
Se il team trova punti su cui intervenire per migliorarlo, l'ADR rimane nello stato Proposto. Il proprietario dell'ADR formula le azioni e, in collaborazione con il resto del team, assegna ciascuna azione a un membro del team. Ogni membro del team può contribuire e risolvere i punti di intervento. È responsabilità del proprietario dell'ADR riprogrammare il processo di revisione.
Il team può anche decidere di rifiutare l'ADR. In questo caso, il proprietario dell'ADR aggiunge un motivo per il rifiuto in modo da evitare future discussioni sullo stesso argomento. Il proprietario modifica lo stato dell'ADR in Respinto.
Se il team approva l'ADR, il proprietario aggiunge un timestamp, una versione e un elenco delle parti interessate. Il proprietario modifica quindi lo stato in Accettato.
Gli ADR e il log delle decisioni creati rappresentano le decisioni prese dal team e forniscono una cronologia di tutte le decisioni. Il team utilizza gli ADR come riferimento durante le revisioni del codice e dell'architettura, ove possibile. Oltre a eseguire revisioni del codice e attività di progettazione e implementazione, i membri del team dovrebbero consultare gli ADR per le decisioni strategiche relative al prodotto.
Il seguente diagramma mostra il processo di applicazione di un ADR per verificare se una modifica in un componente software è conforme alle decisioni concordate.
È buona norma che ogni modifica del software sia sottoposta a revisione tra pari e richieda almeno un'approvazione. Durante la revisione del codice, un revisore potrebbe trovare modifiche che violano uno o più ADR. In tal caso, il revisore chiede all'autore della modifica del codice di aggiornare il codice e condivide un link all'ADR. Quando l'autore aggiorna il codice, questo viene approvato dai revisori e inserito nella base di codice principale.
Processo di revisione dell'ADR
Dopo averli accettati o rifiutati, il team deve trattare gli ADR come documenti non modificabili. Le modifiche a un ADR esistente richiedono la creazione di un nuovo ADR, l'istituzione di un processo di revisione per il nuovo ADR e l'approvazione dello stesso. Se il team approva il nuovo ADR, il proprietario del vecchio ADR deve modificarne lo stato in Sostituito. Il seguente diagramma illustra il processo di aggiornamento.
