

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à.

# Domande frequenti
<a name="faq"></a>

## Quali sono i vantaggi della creazione di un processo ADR?
<a name="q1"></a>

La creazione di un processo ADR da parte del team di progetto consente di semplificare il processo decisionale, evitare continue discussioni sugli stessi argomenti e comunicare in modo efficace le decisioni in materia di progettazione architetturale.

## Quando è necessario creare un ADR?
<a name="q2"></a>

Il team di progetto dovrebbe creare un ADR per ogni aspetto del software che influisce sulla struttura (modelli come i microservizi), sui requisiti non funzionali (sicurezza, alta disponibilità e tolleranza agli errori), sulle dipendenze (accoppiamento di componenti), sulle interfacce (APIse contratti pubblicati) e sulle tecniche di costruzione (librerie, framework, strumenti e processi).

## Con quale frequenza il team di progetto deve esaminare un ADR?
<a name="q3"></a>

Il team di progetto deve esaminare l'ADR almeno una volta prima di accettarlo.

## Chi si occupa della creazione di un ADR?
<a name="q4"></a>

Ogni membro del team può creare un ADR. Ti consigliamo di promuovere un concetto di proprietà per. ADRs L'autore che possiede l'ADR deve mantenere e comunicare attivamente i relativi contenuti. Gli altri membri del team possono sempre contribuire a un ADR. Il proprietario dell'ADR deve approvare le modifiche apportate a un ADR.

## Quali informazioni deve contenere un ADR?
<a name="q5"></a>

Come minimo, ogni ADR deve definire il contesto della decisione, la decisione stessa e le relative conseguenze sul progetto e sui suoi risultati. Il contesto deve indicare le possibili soluzioni prese in considerazione dal team. Deve inoltre contenere tutte le informazioni pertinenti relative al progetto, al cliente o allo stack tecnologico. La decisione deve indicare chiaramente la soluzione che il team ha deciso di adottare, con un linguaggio imperativo. Evita di usare termini come "dovrebbe" e formula ogni decisione con "utilizziamo..." o "il team deve usare...". La sezione relativa alle conseguenze deve menzionare tutti i compromessi noti nell'adottare la decisione. Ogni ADR deve avere uno stato e un log delle modifiche con la data in cui è stata apportata la modifica e la persona che ne è responsabile.

## Dove posso trovare i modelli ADR?
<a name="q6"></a>

Sono disponibili diverse versioni e varianti dei modelli ADR. Per una raccolta pubblica di modelli ADR di uso comune, consultate l'archivio [ GitHub ADR](https://adr.github.io/#existing-adr-templates).