La distinzione formale fornita da Garlan & Shaw separa nettamente i due concetti: l'architettura riguarda l'organizzazione globale, mentre il design scende nel dettaglio dei moduli.
Definizioni di Garlan & Shaw
Architettura del Software: Riguarda l'organizzazione globale del sistema. Definisce la scelta degli elementi strutturali, le loro interazioni a livello macro, le responsabilità e i vincoli generali. Le decisioni architetturali sono estremamente costose da cambiare a posteriori.
Design del Software: Scende nel dettaglio della modularizzazione (il "micro"). Definisce interfacce precise, algoritmi, procedure locali e strutture dati interne ai singoli componenti.
Modelli di Rappresentazione
Dato che l'architettura è complessa, non può essere spiegata con un singolo diagramma. Si utilizzano quindi diversi "punti di vista" (views) per soddisfare i diversi stakeholder.
Modello 4+1 (Kruchten) e Mappatura UML
Ogni vista del modello 4+1 è supportata e documentata da specifici diagrammi UML in sede progettuale:
Vista Logica: Rappresenta i concetti del dominio. Si modella rigorosamente con Class Diagrams (concettuali) e Package Diagrams.
Vista di Sviluppo (Implementation View): Rappresenta la realtà del codice organizzato in moduli fisici (librerie, eseguibili). Si modella tramite Component Diagrams.
Vista di Processo (Process View): Gestisce concorrenza, performance e tolleranza ai guasti a runtime. Si documenta con diagrammi dinamici come Activity Diagrams e Sequence Diagrams.
Vista Fisica (Deployment View): L'infrastruttura di rete e i server. Si mappa strettamente con i Deployment Diagrams.
+1 Scenarios (Use Cases View): Lo scenario che guida e convalida le altre 4 viste. Si rappresenta usando gli Use Case Diagrams.
Modello C4
Un approccio più moderno, orientato all'agilità e alla comunicazione chiara. Fornisce un livello di zoom progressivo (come Google Maps):
Livello 1 - Context: Il sistema nel suo ambiente, mostrando come si relaziona con utenti e altri sistemi esterni.
Livello 2 - Container: Le applicazioni eseguibili singolarmente (es. web app, database, microservizi) che compongono il sistema.
Livello 3 - Component: I blocchi logici principali (es. controller, repository) all'interno di un singolo Container.
Livello 4 - Code: I dettagli implementativi (spesso opzionale o auto-generato dagli IDE, come i diagrammi di classe UML).
Stili e Pattern Architetturali
Esiste una distinzione netta tra Stili Architetturali (paradigmi macro di progettazione come REST, Serverless o Event-Driven) e Pattern Architetturali, ovvero i blocchi costruttivi per implementare quegli stili, classificati in tre macro-categorie.
1. Pattern Logici / Strutturali
Servono per ridurre l'accoppiamento tra moduli (es. Layered, Microkernel, MVC).
Layered: Organizza il sistema in strati orizzontali.
MVC (Model-View-Controller): La distinzione vitale da fare qui è tra:
Traditional Desktop MVC: È reattivo e Stateful, basato largamente sull'Observer Pattern per aggiornare la UI in tempo reale al variare dei dati in memoria.
Web Framework MVC: È sequenziale e Stateless, guidato unicamente dal ciclo di request/response HTTP. Non mantiene lo stato attivo (connessione) con il client.
2. Pattern Fisici / Deployment
Guidano la mappatura tra software e hardware.
Client-Server: L'esame richiede di separare i concetti di Layers (divisione logica del codice) dai Tiers (distribuzione fisica su macchine diverse, es. 2-Tier, 3-Tier).
Peer-to-Peer (P2P): Tutti i nodi sono paritetici (sia client che server). Usato in protocolli di file sharing o Architetture Blockchain.
3. Pattern di Processo / Comunicazione
Definiscono come fluiscono i dati nel sistema a runtime.
Pipe-Filter: Elaborazione dati in sequenza (es. i compilatori). Filtri indipendenti processano i dati in arrivo dai "tubi" (pipe).
Event-Bus / Broker: I componenti non si chiamano direttamente (disaccoppiamento) ma ascoltano ed emettono eventi su un canale condiviso.
Il Cubo della Scalabilità e i Microservizi
La transizione dai monoliti moderni non può prescindere dalla teoria della scalabilità. Il Cubo della Scalabilità (AKF Scale Cube) ci mostra che si può scalare in 3 direzioni:
Gli Assi del Cubo della Scalabilità
Asse X (Cloning): Scalabilità tramite pura duplicazione. Si instanziano N copie esatte del Monolite dietro a un Load Balancer.
Asse Z (Data Partitioning): Si scala separando i dati (es. Sharding del database per Customer ID) ma mantenendo l'app unica.
Asse Y (Functional Decomposition): Scalare dividendo l'applicazione in base alle funzioni. Questa è l'essenza architetturale dei Microservizi veri e propri.
Monolite vs SOA vs Microservizi
Monolite: Unico eseguibile con database condiviso. Semplice da deployare ma blocca la scalabilità selettiva.
SOA (Service-Oriented Architecture): Servizi macro che comunicano via Enterprise Service Bus (ESB), spesso condividendo il DB aziendale per riuso del codice.
Microservizi (Microservices): Servizi indipendenti specializzati con database esclusivi.
I veri Pro: Massima indipendenza dei team, velocità di rilascio continua, scalabilità puntuale.
I veri Contro: Complessità estrema di testing di integrazione, minore performance complessiva a causa del continuo overhead di rete (chiamate HTTP/gRPC invece di chiamate locali in RAM), necessità di DevOps avanzato.
Il Designer TuringBot (L'impatto dell'AI)
L'Intelligenza Artificiale non si limita al coding, ma sta diventando un co-pilota essenziale nella progettazione ad alto livello.
L'AI come Visualizer & Pattern Recommender
Text-to-UML: I TuringBots traducono automaticamente documenti di requisiti testuali nei diagrammi richiesti dal Modello 4+1 (es. generano PlantUML per Class Diagram e Sequence Diagram in pochi secondi).
Trade-off Evaluation: Gli LLM analizzano i vincoli (budget, expertise del team, Time-to-Market) e forniscono raccomandazioni argomentate sul bivio tra Architettura Monolitica o Microservizi.
Discovery Architetturale: Nei sistemi legacy, l'AI esamina il codice sorgente per estrarre la vista logica e ricostruire l'architettura effettiva, evidenziando il divario tra Design Inteso e Design Reale.