Architettura a Microservizi 9 min
Monolite o Microservizi?
Valutare prima la qualità del monolite e la necessità reale di autonomia, scalabilità o isolamento.
Apri la capsula →HUB DI CONOSCENZA · 60 CAPSULE
Design Pattern dei Microservizi
Pattern architetturali e applicativi per progettare microservizi, governare dati ed eventi, costruire resilienza e modernizzare sistemi legacy.
Architettura a Microservizi 8 min
Modular Monolith: il passo spesso più importante
Organizzare l'applicazione in moduli con ownership, API interne e dipendenze controllate, conservando un unico deploy quando la distribuzione non porta ancora un beneficio netto.
Apri la capsula →Architettura a Microservizi 8 min
Principi dei Microservizi e trade-off reali
Progettare per autonomia, failure isolation, evoluzione indipendente, delivery automatizzata e governance decentralizzata, accettando esplicitamente la complessità della distribuzione.
Apri la capsula →
Decomposizione dei Servizi 8 min
Decompose by Business Capability
Definire i servizi intorno a capability aziendali stabili, con dati, regole e casi d'uso coerenti.
Apri la capsula →
Decomposizione dei Servizi 7 min
Decompose by Subdomain
Usare i subdomain del Domain-Driven Design per individuare responsabilità e investimenti differenti.
Apri la capsula →Domain-Driven Design 8 min
Bounded Context: proteggere il significato del dominio
Definire confini semantici entro cui un modello ha significato univoco e non condividere automaticamente lo stesso domain model tra servizi.
Apri la capsula →Dati e Consistenza Distribuita 8 min
Two-Phase Commit (2PC): consistenza forte e coordinamento
Il coordinatore esegue una fase PREPARE e, se tutti i partecipanti sono pronti, una fase COMMIT; altrimenti ordina il ROLLBACK.
Apri la capsula →Dati e Consistenza Distribuita 9 min
Saga Pattern: transazioni locali e compensazioni
Scomporre il processo in transazioni locali coordinate da eventi o da un orchestratore; in caso di errore eseguire azioni compensative di business.
Apri la capsula →Dati e Consistenza Distribuita 7 min
Saga Orchestration
Usare un orchestratore che mantiene lo stato della Saga e invia comandi ai partecipanti, decidendo step successivi e compensazioni.
Apri la capsula →Dati e Consistenza Distribuita 7 min
Saga Choreography
Ogni servizio reagisce a eventi di dominio e pubblica nuovi eventi, formando un flusso emergente.
Apri la capsula →Modernizzazione Legacy 8 min
Strangler Fig Pattern
Affiancare il nuovo sistema al legacy, spostando progressivamente capability e traffico attraverso un livello di routing fino a poter eliminare le parti sostituite.
Apri la capsula →Resilienza 7 min
Bulkhead Pattern
Separare pool, connessioni, code o quote di risorse per limitare la propagazione del guasto.
Apri la capsula →Architettura a Microservizi 7 min
Sidecar Pattern
Affiancare al processo applicativo un componente con ciclo di vita collegato che fornisce proxy, telemetry, certificate management o altre capability trasversali.
Apri la capsula →Integrazione tra Microservizi 8 min
API Gateway Pattern
Esporre un punto d'ingresso che instrada le API e applica concern trasversali come autenticazione, TLS, rate limiting e correlation ID.
Apri la capsula →Integrazione tra Microservizi 7 min
Aggregator Pattern
Introdurre un componente che effettua le chiamate necessarie e restituisce un payload aggregato al consumer.
Apri la capsula →Frontend Distribuito 8 min
Backend for Frontend (BFF)
Creare un backend specifico per esperienza client che orchestra API interne e restituisce modelli orientati alla UI.
Apri la capsula →Integrazione tra Microservizi 6 min
Proxy Pattern
Interporre un proxy stabile che inoltra le richieste verso le istanze reali.
Apri la capsula →Integrazione tra Microservizi 6 min
Gateway Routing Pattern
Definire regole di routing per host, path, header o versione che mappano richieste esterne verso servizi interni.
Apri la capsula →Integrazione tra Microservizi 7 min
Chained Microservices Pattern
Creare una catena corta e intenzionale, con timeout e contratti chiari, evitando sequenze profonde che amplificano latenza e failure probability.
Apri la capsula →Integrazione tra Microservizi 6 min
Branch Pattern
Eseguire in parallelo le chiamate indipendenti e aggregare i risultati, controllando timeout e failure parziali.
Apri la capsula →Frontend Distribuito 7 min
Client-Side UI Composition
Comporre la UI nel client, assegnando sezioni o componenti a fonti e responsabilità diverse.
Apri la capsula →Frontend Distribuito 8 min
Microfrontend
Suddividere il frontend in vertical slice con ownership chiara, integrati da una shell e da contratti di composizione.
Apri la capsula →
Dati e Consistenza Distribuita 8 min
Database per Service
Ogni servizio possiede il proprio modello di persistenza e gli altri accedono ai suoi dati tramite API o eventi.
Apri la capsula →Dati e Consistenza Distribuita 7 min
Shared Database Pattern
Più servizi condividono temporaneamente un database, idealmente con ownership di tabelle o schemi e regole rigorose.
Apri la capsula →Dati e Consistenza Distribuita 8 min
CQRS
Separare command model e query/read model, eventualmente con storage, schemi e scalabilità differenti.
Apri la capsula →Dati e Consistenza Distribuita 7 min
Materialized View / Read Model
Costruire una proiezione locale denormalizzata, aggiornata da eventi o processi controllati, pensata per uno specifico read path.
Apri la capsula →Dati e Consistenza Distribuita 9 min
Event Sourcing
Persistire la sequenza immutabile degli eventi di dominio e derivare lo stato applicando gli eventi in ordine.
Apri la capsula →Dati e Consistenza Distribuita 9 min
Transactional Outbox
Salvare l'evento in una tabella outbox nella stessa transazione del dato di business e pubblicarlo successivamente con un relay affidabile.
Apri la capsula →Dati e Consistenza Distribuita 7 min
Inbox Pattern
Registrare gli identificativi dei messaggi processati in una inbox locale e usare tale registro per deduplicare.
Apri la capsula →Dati e Consistenza Distribuita 7 min
Idempotent Consumer
Progettare il consumer affinché ripetere la stessa operazione produca lo stesso risultato osservabile e non side effect duplicati.
Apri la capsula →Event-Driven Architecture 7 min
Domain Event
Pubblicare eventi al passato che rappresentano fatti già avvenuti e significativi per il dominio.
Apri la capsula →Event-Driven Architecture 9 min
Event-Driven Architecture
Usare eventi asincroni per propagare fatti, aggiornare proiezioni e attivare processi senza dipendenza diretta tra producer e consumer.
Apri la capsula →Event-Driven Architecture 6 min
Publish / Subscribe
Pubblicare l'evento su un exchange/topic e creare subscription/code indipendenti per ogni consumer.
Apri la capsula →Event-Driven Architecture 7 min
Dead Letter Queue (DLQ)
Dopo un numero o una classe di failure stabilita, spostare il messaggio in una DLQ per analisi e replay controllato.
Apri la capsula →Observability 7 min
Log Aggregation
Centralizzare i log di tutti i servizi in una piattaforma ricercabile, preservando servizio, ambiente, timestamp, trace/correlation ID e campi di dominio consentiti.
Apri la capsula →Observability 6 min
Structured Logging
Produrre log strutturati con campi stabili, idealmente JSON, separando messaggio umano e attributi macchina.
Apri la capsula →Observability 6 min
Correlation ID
Assegnare un identificatore di correlazione all'ingresso e propagarlo tra servizi, log e messaggi.
Apri la capsula →Observability 8 min
Distributed Tracing
Rappresentare la richiesta come una trace composta da span per ogni hop o operazione, propagando il contesto tra HTTP e messaging.
Apri la capsula →Observability 8 min
Metriche, RED e USE
Misurare servizi con RED (Rate, Errors, Duration) e risorse con USE (Utilization, Saturation, Errors), aggiungendo metriche di dominio e dipendenze.
Apri la capsula →Observability 7 min
Health Check: Liveness e Readiness
Esporre health endpoint distinti per liveness e readiness, evitando di confondere salute del processo con disponibilità di tutte le dipendenze.
Apri la capsula →Delivery e Runtime 7 min
External Configuration
Separare la configurazione dall'artefatto e iniettarla a runtime tramite environment, config file, secret store o configuration service.
Apri la capsula →Delivery e Runtime 6 min
Service Discovery
Risoluzione dei servizi tramite nome logico e registry/DNS aggiornato automaticamente.
Apri la capsula →Resilienza 8 min
Circuit Breaker
Aprire il circuito dopo una soglia di errori; fallire velocemente durante OPEN; sondare il recupero in HALF_OPEN.
Apri la capsula →Resilienza 7 min
Timeout Pattern
Definire connect, read/request e, dove applicabile, deadline end-to-end coerenti con l'SLO del caso d'uso.
Apri la capsula →Resilienza 8 min
Retry, Exponential Backoff e Jitter
Ritentare solo errori transitori e operazioni idempotenti, usando exponential backoff, jitter e un numero massimo di tentativi.
Apri la capsula →Delivery e Runtime 7 min
Blue-Green Deployment
Mantenere due ambienti equivalenti: BLUE attivo e GREEN candidato.
Apri la capsula →Delivery e Runtime 7 min
Canary Deployment
Instradare una piccola percentuale di traffico verso la nuova versione, osservare metriche e aumentare progressivamente la quota.
Apri la capsula →Modernizzazione Legacy 8 min
Anti-Corruption Layer (ACL)
Inserire un layer di traduzione tra il nuovo bounded context e il legacy, mantenendo il nuovo linguaggio di dominio pulito.
Apri la capsula →Modernizzazione Legacy 7 min
Adapter Pattern
Definire una porta interna e implementare adapter specifici per le tecnologie o i provider esterni.
Apri la capsula →Modernizzazione Legacy 7 min
Branch by Abstraction
Introdurre un'astrazione comune, collegare vecchia e nuova implementazione e spostare gradualmente il traffico tramite configurazione o feature flag.
Apri la capsula →Modernizzazione Legacy 7 min
Shadow Traffic
Duplicare in modo controllato una richiesta verso il nuovo servizio e ignorarne la risposta operativa, confrontando output e metriche con il sistema attivo.
Apri la capsula →Modernizzazione Legacy 8 min
Parallel Run
Eseguire entrambi i sistemi sugli stessi input, confrontando output, latenze, errori e consistenza, mantenendo uno solo come fonte operativa finché non si raggiungono i criteri di accettazione.
Apri la capsula →Architettura Applicativa 6 min
Controller
Limitare il Controller al protocollo: parsing e validazione superficiale della request, invocazione del caso d'uso, mapping della response e gestione degli status HTTP.
Apri la capsula →Architettura Applicativa 6 min
DTO
Usare Data Transfer Object espliciti per request e response, versionabili indipendentemente dal modello interno.
Apri la capsula →Architettura Applicativa 7 min
Service Layer / Application Service
Usare un Application Service per implementare il caso d'uso e delimitare la transazione locale.
Apri la capsula →Architettura Applicativa 7 min
Domain Model
Rappresentare invarianti e comportamenti nel dominio, usando entity, value object e aggregate coerenti con il bounded context.
Apri la capsula →Architettura Applicativa 6 min
Repository
Definire un'astrazione di persistenza orientata agli aggregate e implementarla in un adapter infrastrutturale.
Apri la capsula →Architettura Applicativa 6 min
Mapper
Centralizzare le trasformazioni tra rappresentazioni senza far dipendere il dominio dai formati esterni.
Apri la capsula →Architettura Applicativa 7 min
Client per Servizi Esterni
Incapsulare la tecnologia di integrazione in un client/adapter che implementa una porta applicativa.
Apri la capsula →Architettura Applicativa 9 min
Hexagonal Architecture / Ports & Adapters
Mettere dominio e casi d'uso al centro; definire porte in ingresso/uscita e adapter per HTTP, database, broker e servizi esterni.
Apri la capsula →