Regole di Business - Software Engineering

Questo documento elenca le regole di business fondamentali del dominio Software Engineering, identificate con codice univoco BR-NNN. Ogni regola è technology-independent e descrive un vincolo invariante sul processo di sviluppo software.

---

BR-001 - Ogni FeatureRequest diventa un Requisito tracciabile

Codice: BR-001 Nome: Una FeatureRequest è tradotta in un Requisito con criteri di accettazione Descrizione: Ogni richiesta di funzionalità è analizzata e tradotta in un Requisito chiaro, verificabile e con criteri di accettazione espliciti, prima di entrare nel Backlog. Un requisito ambiguo o senza criteri di accettazione non è pronto per lo sviluppo. Motivazione: Evitare ambiguità e rework; rendere ogni unità di lavoro verificabile. Priorità: ALTA Attori: Product Owner, Developer Tracciabilità: glossary "Test di Accettazione"; events/domain-events.md evento RequisitoCreato; BC-01.

---

BR-002 - Il codice nuovo è coperto da test

Codice: BR-002 Nome: Ogni UserStory completata include test automatici adeguati Descrizione: Il codice che implementa un comportamento è accompagnato da test unitari e, dove serve, di integrazione. La copertura è significativa (testa comportamento reale, non solo righe). Il TDD è la pratica preferita per il nuovo comportamento. Motivazione: Prevenire regressioni e abilitare il refactoring sicuro. Priorità: ALTA Attori: Developer, Tester Tracciabilità: glossary "Test-Driven Development (TDD)", "Test Unitario", "Test di Integrazione"; BR-005.

---

BR-003 - Ogni cambiamento passa per code review

Codice: BR-003 Nome: Nessun codice è integrato senza una revisione tra pari Descrizione: Ogni UserStory in stato implementato deve superare la code review prima del merge. La review verifica correttezza, leggibilità, aderenza ai principi (SOLID), assenza di code smell e copertura di test. Motivazione: Migliorare la qualità, condividere la conoscenza e ridurre i difetti. Priorità: ALTA Attori: Developer Violazione: merge bloccato finché la review non è approvata. Tracciabilità: glossary "Code Smell", "SOLID", "Refactoring"; state-machines/user-story-lifecycle.md stato code-review.

---

BR-004 - La direzione delle dipendenze rispetta la Clean Architecture

Codice: BR-004 Nome: La logica di business non dipende dai dettagli infrastrutturali Descrizione: Nel Codebase, il dominio non dipende da framework, database o UI: la freccia di dipendenza punta verso l'interno. La logica di business è pura e testabile in isolamento (Dependency Injection, Inversion of Control). Motivazione: Mantenere il dominio testabile, sostituibile e indipendente dalla tecnologia. Priorità: CRITICA Attori: Developer Tracciabilità: glossary "Clean Architecture", "Dependency Injection (DI)", "Inversion of Control (IoC)", "Funzione Pura".

---

BR-005 - La build deve restare verde

Codice: BR-005 Nome: Una build fallita blocca l'integrazione finché non è ripristinata Descrizione: Il Codebase mantiene una Continuous Integration con build e test sempre verdi sul ramo principale. Un commit che rompe la build (BuildFallita) ha priorità di fix immediata; nessun nuovo lavoro è integrato su una build rotta. Motivazione: Garantire un ramo principale sempre rilasciabile. Priorità: ALTA Attori: Developer, Tester Violazione: BuildFallita; il ramo principale è congelato finché la build non torna verde. Tracciabilità: glossary "Continuous Integration (CI)"; events/domain-events.md evento BuildFallita.

---

BR-006 - Lo SprintGoal è l'unità di impegno

Codice: BR-006 Nome: Ogni sprint persegue uno SprintGoal con un Backlog selezionato Descrizione: Lo sviluppo è organizzato in iterazioni con un obiettivo (SprintGoal) e un insieme di UserStory selezionate dal Backlog ordinato per priorità. Lo scope dello sprint è protetto: nuove richieste vanno nel backlog, non nello sprint in corso. Motivazione: Garantire focus, prevedibilità e consegna incrementale di valore. Priorità: MEDIA Attori: Product Owner, Scrum Master, Developer Tracciabilità: glossary "Bounded Context"; events/domain-events.md evento SprintAvviato.

---

BR-007 - Il debito tecnico è tracciato e gestito

Codice: BR-007 Nome: Ogni Debito Tecnico introdotto è registrato e pianificato Descrizione: Le scorciatoie implementative (code smell, duplicazione, copertura insufficiente) sono rese visibili come debito tecnico, valutate e inserite nel Backlog. Non si accumula debito invisibile che degrada la MetricaQualità. Motivazione: Mantenere la manutenibilità del codebase nel tempo. Priorità: ALTA Attori: Developer, Product Owner Tracciabilità: glossary "Debito Tecnico", "Refactoring"; events/domain-events.md evento DebitoTecnicoRegistrato.

---

BR-008 - Una release è rilasciata da un ramo verde e testato

Codice: BR-008 Nome: Una ReleaseDistribuita proviene solo da un codebase con build e test verdi Descrizione: Una release è prodotta da uno stato del Codebase con CI verde, copertura adeguata e versionamento semantico. Le modifiche breaking incrementano la versione MAJOR; la release è tracciabile ai requisiti che soddisfa. Motivazione: Garantire rilasci affidabili e tracciabili. Priorità: ALTA Attori: Developer, Scrum Master Tracciabilità: glossary "Semantic Versioning (SemVer)", "Compatibilità all'indietro"; events/domain-events.md evento ReleaseDistribuita.