Issue 10079
Un disegno non è l’architettura
Scegli un livello C4 e dichiara il System Boundary: una scala alla volta rende la review utile.
· 5 min
Obiettivo
Disegnare un livello C4 alla volta, nominando scala e System Boundary, invece di mescolare Context e Code sullo stesso foglio.
Prima la scala, poi il disegno
Prima di aprire una Architecture ReviewGlossarioArchitecture ReviewUna conversazione strutturata che valuta una proposta rispetto a driver, rischi e conseguenze.Apri la voce completa, scrivi in alto quale livello C4GlossarioC4Un modello di diagrammi di architettura a quattro livelli: Context, Container, Component e Code.Apri la voce completa stai mostrando: System Context, Container, Component oppure Code. Subito dopo, nomina il System BoundaryGlossarioSystem BoundaryLa linea esplicita attorno alle responsabilità, all’ownership e alle relazioni esterne di un sistema.Apri la voce completa e chiarisci quali elementi restano intenzionalmente fuori. Se la conversazione richiede un’altra scala, apri un secondo disegno invece di aggiungere dettagli al primo. Il valore di C4 non è rappresentare tutto, ma consentire di nascondere tre livelli per discutere quello rilevante. Un Context diagram dovrebbe aiutare a decidere responsabilità, attori e dipendenze esterne; un Container diagram dovrebbe chiarire applicazioni, data store, comunicazioni e responsabilità di deployment. Se sullo stesso foglio compaiono utenti, vendor, topic Kafka e classi Java, fermati: non manca completezza, manca una domanda architetturale precisa.
Meno completezza, più decisioni
Separare i livelli riduce l’effetto rassicurante del grande poster completo, ma aumenta la precisione della conversazione. Il guadagno è una review con confini leggibili, partecipanti pertinenti e decisioni verificabili. Il costo è mantenere più viste coerenti e accettare che ogni disegno sia deliberatamente incompleto. Una vista troppo astratta può nascondere vincoli di implementazione; una troppo dettagliata può trascinare stakeholderGlossarioStakeholderUna persona o un gruppo che influenza una decisione o ne sperimenta gli effetti.Apri la voce completa business in discussioni su framework e classi. La scelta della scala dipende quindi dalla decisione da prendere, non dalla quantità di informazioni disponibili. Quando un dettaglio di livello inferiore cambia davvero la decisione, registralo come vincoloGlossarioVincoloUna condizione che limita lo spazio delle soluzioni praticabili e non può essere semplicemente ignorata.Apri la voce completa e affrontalo nella vista appropriata.
Una review di integrazione che deve decidere un confine
Un’azienda sta introducendo una piattaforma ordini che dialoga con e-commerce, ERP e un servizio logistico esterno. Alla prima review, un unico foglio mostra clienti, sistemi aziendali, cluster Kafka, database, microservizi e classi Java. Sicurezza discute autenticazione, Operations parla di partizioni e il business chiede chi possiede lo stato dell’ordine: tutti partecipano, ma il confine resta ambiguo. Il Solution Architect divide la review in due momenti. Nel System Context dichiara il confine della piattaforma ordini e fa decidere responsabilità e dipendenze esterne. In una sessione successiva usa il Container diagram per valutare API, messaging, persistenza e ownership operativa. Le classi restano fuori finché non serve una decisione di design locale. Il risultato non è una documentazione più grande, ma due conversazioni con obiettivi, interlocutori e conseguenze distinti.
Per approfondire
Fonti autorevoli per applicare il modello C4 e scegliere consapevolmente il livello di astrazione. • The C4 model for visualising software architecture - Simon Brown - https://c4model.com/ • Diagrams - arc42 Documentation - https://docs.arc42.org/section-5/