linee-guida-architettura-software

SKILL.md

---
name: linee-guida-architettura-software
description: Applica indicazioni contestuali sull'architettura software durante l'analisi dei confini del sistema, dei requisiti di qualità, della comunicazione, degli stili, delle decisioni, dei rischi o dell'evoluzione.
---

# Linee guida per l'architettura software

Usa questa bozza portatile per supportare il lavoro di architettura in diversi domini software. Non è installata globalmente. Il libro fornisce concetti e compromessi; questa guida li rende operativi come controlli condizionali. Non sono comandi di progetto né sostituti dell'intento dell'utente, della governance locale o di evidenze di sistema note.

## Flusso di lavoro

1. **Stabilire contesto e autorità.** Identificare il dominio, il confine del sistema, gli obiettivi di business, i vincoli di deployment e dati, le capacità del team, le evidenze note, le incognite e l'autorità decisionale. Rispettare l'autorità già delegata. Chiedere solo i fatti mancanti che possono cambiare il risultato; altrimenti fornire una raccomandazione condizionale.
2. **Classificare i driver.** Tradurre gli obiettivi degli stakeholder in caratteristiche architetturali. Testare ogni candidato rispetto alla definizione in tre parti, decomporre le qualità composite e dare priorità a un piccolo insieme.
3. **Mappare confini e dati.** Identificare responsabilità funzionali, dipendenze, transazioni, proprietà dei dati, accoppiamento statico, chiamate a runtime e caratteristiche a ogni confine rilevante.
4. **Confrontare proporzionalmente.** Per una scelta rilevante, confrontare almeno due opzioni valide rispetto alle priorità dichiarate, costi, rischi ed evidenze. Non forzare un confronto formale per un cambiamento piccolo e reversibile.
5. **Decidere con motivazione.** Esporre la raccomandazione o lo stato, perché è adatta, i costi accettati, le assunzioni e quali evidenze causerebbero una revisione. Seguire l'autorità delegata; non inventare passaggi di approvazione.
6. **Specificare i controlli.** Scegliere misure o funzioni di fitness proporzionali al rischio. Nominare il loro ambito, segnale, limitazioni e risposta.

## Regole fondamentali

- Basare le raccomandazioni sul contesto ([regole di contesto e priorità](references/rulebook.md#context-priorities): F01) e rispettare l'autorità delegata ([regole di decisione, rischio ed evoluzione](references/rulebook.md#decisions-risk-evolution): D03).
- Derivare e classificare le caratteristiche da risultati misurabili degli stakeholder ([regole di contesto e priorità](references/rulebook.md#context-priorities): F05, F06, F07, F08, F18).
- Mantenere le responsabilità coese e i confini onesti riguardo a dipendenze e accoppiamento ([regole sui confini](references/rulebook.md#boundaries-coupling-data): F11–F17, S03, S08; [glossario](references/glossary.md)).
- Scegliere la comunicazione per il lavoro; distinguere richiesta, comando ed evento, e progettare per il fallimento ([regole di comunicazione](references/rulebook.md#communication-reliability): S06, S09–S13, S15, D08).
- Trattare gli stili architetturali come opzioni condizionali e confrontarne i costi ([regole di stile](references/rulebook.md#style-choice): S01, S16, D06; [guida di stile](references/style-selection.md)).
- Registrare perché esistono decisioni rilevanti e cosa le cambierebbe ([compromessi](references/rulebook.md#context-priorities): F02; [registri di decisione](references/rulebook.md#decisions-risk-evolution): F03).
- Rendere visibili rischio, incertezza e allineamento all'implementazione ([regole di rischio ed evoluzione](references/rulebook.md#decisions-risk-evolution): D10, D11, D12, D13).
- Governare vincoli importanti con controlli comprensibili ([regole di governance](references/rulebook.md#decisions-risk-evolution): F09, F10).
- Preservare la scelta del team entro l'effettiva autorità e vincoli ([regole di team e comunicazione](references/rulebook.md#communication-teams): S04, D16, D17, D18).
- Applicare indicazioni specifiche del provider solo quando il progetto include un provider di modelli ([D15 in rules.json](references/rules.json)).

## Contratto di output

Restituire: contesto e incognite; raccomandazione e stato; alternative e costi; implicazioni su confini, dati e comunicazione; evidenze e controlli; e un trigger di revisione. Scalare il dettaglio in base alla conseguenza della scelta.

## Riferimenti

Per un compito, caricare solo la categoria rilevante in [rules.json](references/rules.json) o leggere la sua sezione in [rulebook.md](references/rulebook.md), non entrambi o l'intero pacchetto. Caricare [style-selection.md](references/style-selection.md) per i nove stili, [glossary.md](references/glossary.md) per termini basati sulla fonte, e [source-map.json](references/source-map.json) per localizzare i capitoli citati. I prompt di valutazione sintetica sono in [evaluation-cases.json](references/evaluation-cases.json); non sono stati eseguiti. Metodo e limitazioni sono in [method-and-validation.md](references/method-and-validation.md).