Un’applicazione diventa difficile da cambiare quando ogni componente conosce troppi dettagli degli altri. API ed eventi creano confini espliciti, ma richiedono contratti, responsabilità e osservabilità: non basta aggiungere un endpoint.
Confini prima della tecnologia
Un buon confine segue capacità di business e proprietà dei dati. Ordini, clienti e pagamenti non sono cartelle di codice, ma domini con regole e responsabili.
Prima di dividere un sistema è utile mappare flussi e cambiamenti frequenti. Separare troppo presto aumenta rete, deployment e diagnosi senza offrire vera autonomia.
Contratti affidabili
API prevedibili usano nomi coerenti, errori comprensibili, versionamento e idempotenza. Documentazione ed esempi devono essere testati insieme al codice.
Compatibilità all’indietro e deprecazioni graduali permettono ai consumer di aggiornarsi senza rilasci coordinati. Il contratto diventa un prodotto interno.
Quando usare gli eventi
Gli eventi sono adatti a comunicare fatti avvenuti e a disaccoppiare reazioni successive. Non sostituiscono automaticamente richieste sincrone né cancellano la necessità di gestire errori.
Duplicati, ordine e ritardi sono condizioni normali. Consumer idempotenti, dead-letter queue e tracciamento end-to-end devono essere previsti dall’inizio.
Evoluzione controllata
Test di contratto, metriche per endpoint e correlation ID riducono il costo operativo. Un catalogo aiuta a sapere chi produce e consuma ogni interfaccia.
L’architettura migliore non è quella con più componenti, ma quella che consente cambiamenti indipendenti dove servono e mantiene semplice tutto il resto.
Il costo nascosto delle integrazioni senza proprietario
Quando nessuno possiede un'API, errori e cambiamenti vengono risolti con accordi informali. La documentazione invecchia, i consumer dipendono da comportamenti casuali e ogni rilascio richiede coordinamento. Assegnare ownership significa definire supporto, compatibilità, qualità dei dati e percorso di evoluzione.
Anche gli eventi hanno bisogno di un significato stabile. Un nome come ordineAggiornato è troppo generico: non spiega cosa è cambiato né perché un consumer dovrebbe reagire. Eventi basati su fatti di dominio, schema versionato ed esempi reali riducono interpretazioni divergenti nel tempo.
Domande frequenti
API e microservizi sono la stessa cosa?
No. Un'API è un contratto di comunicazione e può esporre un monolite, un microservizio oppure un sistema esterno.
Quando è meglio usare un evento?
Quando si comunica un fatto avvenuto e più componenti possono reagire senza bloccare chi lo ha prodotto.