ADR (Architecture Decision Record)
Un ADR è un documento breve e immutabile che registra una decisione architetturale con il suo contesto, le opzioni, la scelta e le conseguenze. Gli ADR sono versionati con il codice perché la motivazione sopravviva al ricambio del team. Un modello leggero molto diffuso è quello di Michael Nygard.
ATAM (Architecture Tradeoff Analysis Method)
ATAM è un metodo di valutazione architetturale basato su scenari del Software Engineering Institute. Fa emergere come le decisioni architetturali influenzino gli attributi di qualità e identifica rischi, punti di sensibilità e compromessi prima che la costruzione vincoli il team.
BFF (Backend for Frontend)
Un BFF è un componente lato server dedicato a un tipo di client, che aggrega e modella i dati di backend per quella specifica esperienza. Evita di costringere un'unica API generica a soddisfare contemporaneamente client web, mobile e partner.
CAP (Consistency, Availability, Partition tolerance)
CAP nomina le tre proprietà che un archivio dati distribuito non può garantire tutte insieme. Poiché le partizioni sono inevitabili, i sistemi barattano la consistenza con la disponibilità quando se ne verifica una.
PACELC
PACELC estende CAP: in caso di Partizione, si sceglie tra Disponibilità e Consistenza; Else (in funzionamento normale), si sceglie tra Latenza e Consistenza. Cattura il compromesso quotidiano latenza/consistenza che CAP omette.
CQRS (Command Query Responsibility Segregation)
CQRS separa il modello di scrittura (i comandi che cambiano lo stato) dal modello di lettura (le query), permettendo di ottimizzare ciascuno in modo indipendente. È spesso combinata con l'event sourcing e le proiezioni lato lettura.
DDD (Domain-Driven Design)
Il DDD è un approccio di modellazione che allinea il software al business attraverso un linguaggio ubiquo e confini espliciti. Il DDD strategico plasma i confini dei contesti; quello tattico plasma aggregati, entità e value object al loro interno.
SOA (Service-Oriented Architecture)
La SOA struttura un'azienda come servizi a grana grossa, riutilizzabili e individuabili, in comunicazione attraverso uno strato di messaggistica condiviso. È l'antenato concettuale dei microservizi, che la decentralizzano ed eliminano il bus centrale.
EDA (Event-Driven Architecture)
L'EDA è uno stile in cui i componenti comunicano producendo e consumando eventi attraverso un broker o un log, anziché chiamarsi direttamente. Massimizza disaccoppiamento e asincronia al costo di un ragionamento end-to-end più difficile.
ESB (Enterprise Service Bus)
Un ESB è uno strato middleware centralizzato che instrada, trasforma e orchestra i messaggi tra servizi nella SOA classica. I microservizi lo evitano deliberatamente, preferendo "smart endpoints and dumb pipes".
SLA (Service-Level Agreement)
Uno SLA è un impegno contrattuale su un livello di servizio, come il 99,9% di disponibilità mensile, spesso con penali. È l'obiettivo promesso esternamente, derivato dagli SLO interni.
SLO (Service-Level Objective)
Uno SLO è un obiettivo interno per un indicatore di livello di servizio, come il 99,95% delle richieste sotto i 300 ms, che il team si impegna a rispettare. Gli SLO guidano gli error budget e la prioritizzazione nel site reliability engineering.
SLI (Service-Level Indicator)
Un SLI è una misura quantitativa del comportamento di un servizio, come latenza delle richieste, tasso di errore o disponibilità. Gli SLI sono i segnali grezzi rispetto ai quali si valutano gli SLO.
QA (Quality Attribute)
QA, in contesto architetturale, indica una proprietà non funzionale del sistema - prestazioni, scalabilità, sicurezza, modificabilità, disponibilità - che l'architettura esiste per soddisfare. Ciascuna si specifica con uno scenario concreto e verificabile.
NFR (Non-Functional Requirement)
Un NFR specifica un vincolo o una qualità che il sistema deve soddisfare anziché una funzionalità che deve avere, come "latenza p99 sotto i 200 ms". Gli NFR sono in gran parte sinonimo dei requisiti di attributo di qualità e sono il principale motore delle decisioni architetturali.
SPOF (Single Point of Failure)
Uno SPOF è qualunque componente il cui guasto mette giù l'intero sistema. Eliminare gli SPOF tramite ridondanza e failover è una tattica fondamentale di disponibilità.
RTO (Recovery Time Objective)
L'RTO è il tempo massimo accettabile per ripristinare un servizio dopo un'interruzione. È un obiettivo di disaster recovery che plasma l'architettura di failover e backup.
RPO (Recovery Point Objective)
L'RPO è la quantità massima accettabile di perdita di dati misurata in tempo, per esempio "al massimo cinque minuti di dati". Insieme all'RTO guida la frequenza di replicazione e backup.
ACL (Anti-Corruption Layer)
Un ACL è un confine di traduzione che impedisce a un modello esterno o legacy di trapelare e corrompere il modello di un bounded context. È un pattern di integrazione centrale del DDD.
C4
C4 è un modello per diagrammare l'architettura a quattro livelli di zoom: Context, Containers, Components e Code. Standardizza la notazione perché i diagrammi restino coerenti e adeguati al pubblico.
Modello a viste 4+1
Il modello 4+1, introdotto da Philippe Kruchten, descrive l'architettura attraverso le viste logica, di processo, di sviluppo e fisica, più gli scenari che le legano insieme. Indirizza le esigenze di stakeholder diversi con viste diverse.
IaC (Infrastructure as Code)
L'IaC gestisce e fornisce l'infrastruttura tramite file di definizione leggibili da macchina anziché configurazione manuale. Rende gli ambienti riproducibili, versionati e revisionabili, ciò che è fondamentale per l'architettura cloud-native.
CNCF (Cloud Native Computing Foundation)
La CNCF è un progetto della Linux Foundation che ospita e cura progetti open-source cloud-native chiave come Kubernetes, Envoy e Prometheus. Cura il panorama tecnologico cloud-native di fatto.
mTLS (Mutual TLS)
L'mTLS è una sicurezza di trasporto in cui sia il client sia il server si autenticano a vicenda con certificati, non solo il server. Le service mesh lo usano per cifrare e autenticare per default tutto il traffico servizio-a-servizio.
2PC (Two-Phase Commit)
Il 2PC è un protocollo di transazione distribuita che coordina una fase di prepare e una di commit tra i partecipanti per ottenere l'atomicità. Scala male e si blocca in caso di guasto del coordinatore, motivo per cui le saga sono preferite tra servizi autonomi.
DTO (Data Transfer Object)
Un DTO è un oggetto privo di comportamento usato per trasportare dati attraverso un confine architetturale, disaccoppiando il contratto esterno dal modello di dominio interno. È la forma tipica dei payload di richiesta e risposta di un'API.
OLTP / OLAP
I sistemi OLTP (Online Transaction Processing) gestiscono molte transazioni brevi e ad alta scrittura; i sistemi OLAP (Online Analytical Processing) servono query analitiche complesse e ad alta lettura. Le architetture spesso li separano, alimentando l'OLAP dall'OLTP tramite ETL o change-data-capture.
CDC (Change Data Capture)
Il CDC è una tecnica per osservare e trasmettere in streaming i cambiamenti dal log delle transazioni di un database verso i consumatori a valle. È ampiamente usato per mantenere sincronizzati modelli di lettura, indici di ricerca e store analitici senza scritture doppie.