Regole di Business - Software Architecture

Questo documento elenca le regole di business fondamentali del dominio Software Architecture, identificate con codice univoco BR-NNN. Ogni regola è technology-independent e descrive un vincolo invariante sulla progettazione e l'evoluzione di un sistema software.

---

BR-001 - Ogni decisione architetturale significativa è registrata in un ADR

Codice: BR-001 Nome: Le ArchitecturalDecision significative sono documentate come ADR Descrizione: Ogni decisione che influenza la struttura, gli attributi di qualità o i vincoli del sistema deve essere registrata in un Architecture Decision Record con contesto, opzioni considerate, decisione e conseguenze. Le decisioni non documentate non sono ammesse come architettura. Motivazione: Preservare la conoscenza del "perché" oltre al "cosa"; abilitare l'evoluzione informata. Priorità: ALTA Attori: Software Architect, Tech Lead Tracciabilità: glossary "Architecture Decision Record (ADR)"; state-machines/adr-lifecycle.md; BC-01.

---

BR-002 - L'architettura è guidata dagli attributi di qualità

Codice: BR-002 Nome: Le decisioni strutturali derivano dagli attributi di qualità prioritari Descrizione: La scelta di stili e pattern architetturali deve essere giustificata dagli attributi di qualità richiesti (scalabilità, disponibilità, manutenibilità, sicurezza). Un trade-off tra attributi è esplicitato; nessuna decisione strutturale è presa solo per moda tecnologica. Motivazione: Allineare la struttura agli obiettivi non funzionali reali del sistema. Priorità: ALTA Attori: Software Architect, Stakeholder Business Tracciabilità: glossary "Attributo di qualità", "Valutazione dell'architettura (ATAM)"; BR-001.

---

BR-003 - La direzione delle dipendenze rispetta i confini architetturali

Codice: BR-003 Nome: Le Dipendenza puntano verso l'interno, mai dall'interno verso l'esterno Descrizione: In architetture a livelli/esagonali/Clean, il dominio non dipende dall'infrastruttura: la freccia di dipendenza va dall'esterno verso il dominio. Una dipendenza che viola questa direzione è un debito architetturale da correggere. Motivazione: Mantenere il dominio puro e testabile, indipendente da framework e dettagli tecnici. Priorità: CRITICA Attori: Software Architect, Code Reviewer Violazione: VincoloViolato; il merge è bloccato dalla fitness function di dipendenza. Tracciabilità: glossary "Clean Architecture", "Architettura esagonale", "Onion Architecture", "Anti-corruption layer".

---

BR-004 - Alta coesione e basso accoppiamento tra componenti

Codice: BR-004 Nome: Ogni Componente massimizza la coesione interna e minimizza l'accoppiamento esterno Descrizione: Le responsabilità sono raggruppate per coesione; le interazioni tra componenti avvengono tramite interfacce stabili. Un componente che cambia per molte ragioni diverse o che è troppo accoppiato ad altri va riprogettato. Motivazione: Permettere l'evoluzione indipendente e ridurre l'impatto del cambiamento. Priorità: ALTA Attori: Software Architect, Tech Lead Tracciabilità: glossary "Coesione", "Accoppiamento", "Bounded context".

---

BR-005 - Il debito tecnico è reso visibile e gestito

Codice: BR-005 Nome: Ogni TechnicalDebt identificato è registrato, valutato e pianificato Descrizione: Il debito tecnico architetturale (scorciatoie strutturali, violazioni di pattern, componenti deprecati) è reso esplicito, valutato per impatto e interesse, e inserito nel backlog. Non si accumula debito invisibile. Motivazione: Evitare l'erosione silenziosa dell'architettura nel tempo. Priorità: ALTA Attori: Tech Lead, Software Architect Tracciabilità: glossary "Fitness function"; events/domain-events.md evento DebitoTecnicoIdentificato; BR-002.

---

BR-006 - I confini dei componenti seguono la Legge di Conway

Codice: BR-006 Nome: La struttura dei componenti è allineata alla struttura dei team Descrizione: La scomposizione in Componente tiene conto della Legge di Conway: i confini software tendono a rispecchiare i confini di comunicazione organizzativa. Disallineamenti producono attrito e accoppiamento; si applica l'inverse Conway maneuver dove necessario. Motivazione: Ridurre l'attrito organizzativo e favorire l'autonomia dei team. Priorità: MEDIA Attori: Software Architect, Stakeholder Business Tracciabilità: glossary "Legge di Conway", "Bounded context".

---

BR-007 - Un cambiamento breaking richiede versionamento del contratto

Codice: BR-007 Nome: L'evoluzione di un contratto architetturale preserva i consumatori o introduce una nuova versione Descrizione: Quando un Componente espone un'API o un contratto consumato da altri, un cambiamento breaking richiede una nuova versione e un periodo di coesistenza. La deprecazione segue un percorso annunciato. Motivazione: Proteggere i consumatori da regressioni; consentire migrazioni ordinate. Priorità: ALTA Attori: Software Architect, Tech Lead Tracciabilità: glossary "API Gateway", "Idempotenza"; events/domain-events.md evento APIVersionePubblicata.

---

BR-008 - La conformità architetturale è verificata da fitness function

Codice: BR-008 Nome: I vincoli architetturali sono espressi come fitness function automatiche Descrizione: I vincoli strutturali (direzione delle dipendenze, layering, naming, limiti di accoppiamento) sono codificati come fitness function eseguite nella pipeline. Una violazione blocca l'integrazione, evitando l'erosione dell'architettura. Motivazione: Rendere l'architettura verificabile e resistente al degrado. Priorità: ALTA Attori: Code Reviewer, Software Architect Violazione: VincoloViolato; build fallita finché il vincolo non è ripristinato. Tracciabilità: glossary "Fitness function", "Valutazione dell'architettura (ATAM)"; BR-003.