Tagliare per capacità di business
Definire i confini lungo domini e responsabilità chiare. Le parti tecniche che servono la stessa capacità di solito restano nello stesso servizio.
Versione italiana
Microservizi chiari nel dominio, poco accoppiati e facili da gestire.
Questa pagina raccoglie linee guida per microservizi e architettura event-driven: confini dei servizi, contratti degli eventi, osservabilità, deploy e responsabilità dei team.
Fondamenti
Confini dei servizi
Un microservizio non è solo un piccolo deployable. Incapsula una capacità di business, la proprietà dei dati e una responsabilità operativa.
Rispettare la proprietà dei dati
Ogni servizio possiede i propri dati. Gli altri servizi non leggono direttamente il suo database, ma usano API, eventi o read model replicati.
Ridurre l’accoppiamento
Usare le chiamate sincrone con cautela, definire timeout e fallback, ed evitare di pubblicare modelli interni come contratti.
Mantenere autonomia di rilascio
Un servizio dovrebbe poter essere testato, deployato, scalato e ripristinato in modo indipendente. Le librerie condivise restano piccole.
Architettura event-driven
Eventi come fatti di dominio
Gli eventi disaccoppiano i flussi, ma richiedono disciplina su contratti, idempotenza, ordine e gestione degli errori.
Nominare gli eventi al passato
Un evento descrive ciò che è accaduto: OrderPlaced, PaymentCaptured o ContractCancelled. Non è una chiamata remota mascherata.
Versionare i contratti
Gli schemi sono interfacce di produzione. Le modifiche vanno pianificate in modo compatibile, documentate e coperte da consumer test.
Costruire l’idempotenza
I consumer devono tollerare consegne duplicate. Event ID, Aggregate ID, Inbox/Outbox e retry tracciabili sono elementi chiave.
Progettare la consistenza
L’eventual consistency è una scelta di design. Interfacce, SLA e supporto devono rendere comprensibili ritardi e stati intermedi.
Operation
Pronti per la produzione fin dall’inizio
I sistemi distribuiti richiedono disciplina operativa. Senza osservabilità, ownership e resilienza, piccoli servizi creano grandi dipendenze.
Standardizzare l’osservabilità
Propagare metriche, log, trace e correlation ID attraverso servizi ed eventi. Le dashboard combinano segnali di business e tecnici.
Isolare i guasti
Timeout, circuit breaker, bulkhead e dead-letter queue evitano guasti a cascata. I retry hanno limiti, backoff e alert chiari.
Ridurre il rischio di deploy
Test automatici, contract check, migrazioni e release progressive riducono il rischio. Il rollback deve essere una procedura normale.
Rendere visibile l’ownership
Ogni servizio ha un team, un contatto, runbook, SLO e regole esplicite per breaking change.
Pratico
Checklist prima del go-live
Queste domande rendono concrete le decisioni architetturali e mantengono visibili i rischi fin dall’inizio.
Design del servizio
- La responsabilità di business è spiegabile in una frase?
- Il servizio possiede dati e strategia di migrazione?
- API ed eventi pubblici sono documentati e versionati?
- Il team può rilasciare e fare rollback autonomamente?
Flusso event-driven
- Producer, consumer e latenze attese sono noti?
- Gli schemi degli eventi sono compatibili e testati?
- I consumer sono idempotenti e supportano retry?
- Lag, errori e dead letter sono monitorati?
Operation
- SLO, alert e runbook sono disponibili?
- Il tracing attraversa confini sincroni e asincroni?
- Secrets, accessi e classificazione dati sono verificati?
- Capacità, costi e limiti di scaling sono compresi?