Architetture Software

Definizione

L'architettura software descrive la struttura di alto livello di un sistema software: componenti, relazioni, principi di progettazione, vincoli e decisioni che riguardano qualità (performance, scalabilità, manutenibilità, sicurezza). Distinta dal design (livello dettaglio) e dall'implementazione (codice).

Drivers architetturali

• Requisiti funzionali (cosa fa il sistema)
• Requisiti non funzionali / qualità (performance, sicurezza, scalabilità, usabilità)
• Vincoli (tecnologici, normativi, budget, time-to-market)
• Stakeholder concerns (utenti, business, dev, ops)

Caratteristiche di qualità ISO/IEC 25010

1. Functional suitability
2. Performance efficiency
3. Compatibility
4. Usability
5. Reliability
6. Security
7. Maintainability
8. Portability

Architectural views (4+1 — Kruchten)

• Logical (oggetti, classi)
• Process (concorrenza, sincronizzazione)
• Physical (deployment)
• Development (organizzazione moduli)
• +1 Scenarios (use case che validano le altre 4)

Stili classici

Stile	Caratteristica	Quando usarlo
Monolithic	Tutto in un unico deployment	Piccoli sistemi, MVP
Layered (n-tier)	Strati orizzontali (presentation/business/data)	Sistemi enterprise tradizionali
Client-Server	Client richiede, server risponde	Web, DBMS
Pipe-and-Filter	Trasformazioni in cascata	ETL, compilatori, Unix shell
Event-Driven	Componenti reagiscono a eventi	UI, IoT, real-time
Microkernel / Plug-in	Core minimale + estensioni	IDE (Eclipse), browser
Microservices	Servizi piccoli, indipendenti, distribuiti	Sistemi cloud-scale
Service-Oriented (SOA)	Servizi riusabili tramite ESB	Integrazione enterprise
Serverless / FaaS	Funzioni eventi-driven gestite dal cloud	Workload sporadici, scala automatica

Layered architecture (3-tier classico)

1. Presentation Layer (UI, controller)
2. Business Logic Layer (servizi, dominio)
3. Data Access Layer (repository, DAO, DBMS)

Variante Hexagonal / Ports & Adapters (Cockburn, 2005): dominio al centro, dipendenze invertite verso l'esterno.

Clean Architecture (Robert C. Martin, 2017)

Cerchi concentrici: Entities → Use Cases → Interface Adapters → Frameworks/Drivers. Dependency Rule: dipendenze SOLO verso il centro.

MVC, MVP, MVVM

• MVC (Model-View-Controller): Model gestisce dati, View presenta, Controller coordina
• MVP (Model-View-Presenter): Presenter media tra View e Model, View passiva
• MVVM (Model-View-ViewModel): binding bidirezionale via ViewModel (WPF, Angular, Vue)

Caratteristiche

• Servizi piccoli e con responsabilità singola
• Database per servizio (no shared DB)
• Comunicazione via API (REST, gRPC) o messaging asincrono (Kafka, RabbitMQ)
• Deployment indipendente (CI/CD per servizio)
• Tecnologie eterogenee (polyglot persistence/programming)
• Resilienza tramite Circuit Breaker, Bulkhead, Retry

Vantaggi vs svantaggi

Vantaggi	Svantaggi
Scalabilità orizzontale per servizio	Complessità operativa (orchestrazione)
Deploy indipendente	Latenza rete inter-servizio
Team autonomi	Consistenza dati distribuita (no ACID globale)
Tecnologie miste	Debugging e tracing complessi
Isolamento fallimenti	Costi infrastruttura più alti

Pattern correlati

• API Gateway: punto unico ingresso, routing, autenticazione, rate limiting
• Service Discovery: registro dinamico (Consul, Eureka, Kubernetes Service)
• Circuit Breaker (Hystrix, Resilience4j): protegge da cascade failure
• Saga: transazioni distribuite tramite compensazione
• CQRS (Command Query Responsibility Segregation): separa comandi (write) da query (read)
• Event Sourcing: stato derivato da log eventi immutabili

Containerizzazione

• Docker: standard de facto per packaging applicazioni
• OCI (Open Container Initiative): standard immagini e runtime
• Container vs VM: container condividono kernel host, partono in secondi, leggeri (MB invece di GB)

Kubernetes (K8s)

Orchestratore container, sviluppato Google, donato a CNCF (2014).

Componenti control plane:

• API Server — endpoint REST
• etcd — store distribuito chiave-valore (configurazione cluster)
• Scheduler — assegna pod ai nodi
• Controller Manager — riconcilia stato

Componenti node:

• kubelet — agente locale
• kube-proxy — networking
• Container runtime (containerd, CRI-O)

Oggetti chiave:

• Pod — unità minima deployabile (1+ container)
• Deployment — gestione replicas
• Service — networking stabile (ClusterIP, NodePort, LoadBalancer)
• Ingress — accesso HTTP esterno
• ConfigMap / Secret — configurazione
• PersistentVolume — storage persistente

CNCF Landscape

Cloud Native Computing Foundation, ospita 180+ progetti: Kubernetes, Prometheus, Envoy, Istio, Helm, Argo, OpenTelemetry.

Service mesh

Istio, Linkerd: gestione comunicazione inter-servizi (load balancing, mutual TLS, observability) tramite sidecar proxy.

REST (Representational State Transfer — Fielding, 2000)

Stile architetturale basato su HTTP. Vincoli:

1. Client-Server
2. Stateless (no sessione lato server)
3. Cacheable
4. Uniform interface (URI risorse, metodi HTTP, HATEOAS)
5. Layered system
6. Code on demand (opzionale)

Verbi HTTP: GET (read), POST (create), PUT (update full), PATCH (update partial), DELETE.

Status code:

• 1xx informational
• 2xx success (200 OK, 201 Created, 204 No Content)
• 3xx redirection (301, 302, 304)
• 4xx client error (400, 401, 403, 404, 429)
• 5xx server error (500, 502, 503, 504)

GraphQL (Facebook, 2015)

Query language per API: il client specifica esattamente i campi richiesti, single endpoint, no over/under-fetching. Schema fortemente tipizzato.

gRPC (Google, 2015)

RPC moderno basato su HTTP/2 + Protocol Buffers. Bidirectional streaming, performance elevata, ideale comunicazione inter-servizio.

SOAP / WSDL

Protocollo XML enterprise (anni 2000), pesante ma con WS-Security/WS-Transaction. In declino, sopravvive in legacy bancari.

Webhooks

Pattern push: il server chiama un URL del client al verificarsi di un evento. Asincrono, leggero.

SOLID (Robert C. Martin)

Lettera	Principio	Significato
S	Single Responsibility	Una classe = una sola ragione per cambiare
O	Open/Closed	Aperto a estensioni, chiuso a modifiche
L	Liskov Substitution	Sottoclassi sostituibili a superclassi
I	Interface Segregation	Interfacce piccole e specifiche
D	Dependency Inversion	Dipendere da astrazioni, non da implementazioni

Altri principi

• DRY (Don't Repeat Yourself)
• KISS (Keep It Simple, Stupid)
• YAGNI (You Aren't Gonna Need It)
• Separation of Concerns
• Law of Demeter (principio di minima conoscenza)
• Composition over inheritance

Design Pattern (Gang of Four, 1994)

Creational: Singleton, Factory Method, Abstract Factory, Builder, Prototype.

Structural: Adapter, Bridge, Composite, Decorator, Facade, Flyweight, Proxy.

Behavioral: Observer, Strategy, Command, Iterator, State, Template Method, Visitor, Mediator, Memento, Chain of Responsibility, Interpreter.

CI/CD (Continuous Integration / Continuous Delivery / Deployment)

• CI: integrazione frequente con build + test automatici (Jenkins, GitLab CI, GitHub Actions)
• CD: rilascio automatico in staging/produzione
• Pipeline tipiche: lint → test unit → build → test integration → security scan → deploy

Strategie di deployment

Strategia	Caratteristica	Rischio
Recreate	Stop vecchio, deploy nuovo	Downtime
Rolling Update	Sostituzione graduale	Versioni miste temporanee
Blue-Green	2 ambienti, switch traffic	Costi raddoppiati
Canary	% traffico graduale al nuovo	Monitoring critico
A/B Testing	Versioni diverse a segmenti utenti	Logica routing

Infrastructure as Code (IaC)

Terraform (provisioning multi-cloud), Ansible (configuration management), Pulumi (IaC con linguaggi general purpose), CloudFormation (AWS).

Observability — 3 pilastri

1. Logs (ELK stack, Loki)
2. Metrics (Prometheus, Grafana)
3. Traces (Jaeger, Zipkin, OpenTelemetry)