Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
# Schemi per la decomposizione di monoliti
Dopo aver deciso di scomporre un monolite nel portafoglio di applicazioni, è necessario scegliere i modelli di scomposizione appropriati e introdurli nell'organizzazione.
**Nota**
È possibile utilizzare più modelli per scomporre un monolite. [Ad esempio, è possibile scomporre un monolite in base alle [capacità aziendali](decompose-business-capability.md) e quindi utilizzare il modello di sottodominio per suddividerlo ulteriormente.](decompose-subdomain.md)
**Topics**
+ [Scomponi in base alla capacità aziendale](decompose-business-capability.md)
+ [Decomponi per sottodominio](decompose-subdomain.md)
+ [Scomponi per transazioni](decompose-transactions.md)
+ [Modello di servizio per team](service-per-team.md)
+ [Motivo a fico Strangler](strangler-fig.md)
+ [Ramo per modello di astrazione](branch-by-abstraction.md)
# Scomponi in base alla capacità aziendale
È possibile utilizzare i processi o le funzionalità aziendali dell'organizzazione per scomporre un monolite. Una *capacità aziendale* è ciò che un'azienda fa per generare valore (ad esempio, vendite, assistenza clienti o marketing). In genere, un'organizzazione ha diverse capacità aziendali e queste variano in base al settore o all'industria. Utilizzate questo schema se il team dispone di informazioni sufficienti sulle unità aziendali dell'organizzazione e se avete esperti in materia (SMEs) per ogni unità aziendale. La tabella seguente illustra i vantaggi e gli svantaggi dell'utilizzo di questo modello.
****
| Vantaggi | Svantaggi |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-business-capability.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-business-capability.html) |
Nel diagramma seguente, un monolite assicurativo è scomposto in quattro microservizi in base alle capacità aziendali.
![\[Scomposizione dei monoliti in base alle funzionalità aziendali\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-business-capability.png)
# Decomponi per sottodominio
Questo modello utilizza un sottodominio [DDD (Domain-Driven Design)](https://en.wikipedia.org/wiki/Domain-driven_design) per scomporre i monoliti. *Questo approccio suddivide il modello di dominio dell'organizzazione in sottodomini separati etichettati come *principali* (un elemento di differenziazione chiave per l'azienda), di *supporto (probabilmente correlati al business ma non come elemento di differenziazione) o generici (non* specifici dell'azienda).* Questo modello è appropriato per i sistemi monolitici esistenti che hanno confini ben definiti tra i moduli relativi ai sottodomini. Ciò significa che è possibile scomporre il monolite riconfezionando i moduli esistenti come microservizi, ma senza riscrivere in modo significativo il codice esistente. *Ogni sottodominio ha un modello e l'ambito di tale modello è chiamato contesto limitato.* I microservizi sono sviluppati attorno a questo contesto limitato. La tabella seguente illustra i vantaggi e gli svantaggi dell'utilizzo di questo modello.
****
| Vantaggi | Svantaggi |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-subdomain.html) |
L'illustrazione seguente mostra come un monolite assicurativo può essere scomposto in sottodomini dopo essere stato scomposto dalle funzionalità aziendali.
![\[Scomposizione dei monoliti per sottodomini\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-subdomain.png)
L'illustrazione mostra che i servizi di *vendita* e *marketing* sono suddivisi in microservizi più piccoli. I modelli *Purchasing* e *Claims* sono importanti fattori di differenziazione aziendale per *le vendite* e sono suddivisi in due microservizi separati. *Il *marketing* viene scomposto utilizzando funzionalità aziendali di supporto come *Campaigns*, *Analytics* e Reports.*
# Scomponi per transazioni
In un sistema distribuito, un'applicazione in genere deve chiamare più microservizi per completare una transazione commerciale. Per evitare problemi di latenza o problemi di commit in due fasi, puoi raggruppare i microservizi in base alle transazioni. Questo schema è appropriato se consideri importanti i tempi di risposta e i diversi moduli non creano un monolite dopo averli impacchettati. La tabella seguente illustra i vantaggi e gli svantaggi dell'utilizzo di questo modello.
****
| Vantaggi | Svantaggi |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/decompose-transactions.html) |
Nella figura seguente, il monolito assicurativo è suddiviso in più microservizi basati sulle transazioni.
![\[Scomposizione dei monoliti per transazioni\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/decompose-by-transaction.png)
In un sistema assicurativo, una richiesta di sinistro viene in genere contrassegnata a un cliente dopo l'invio. Ciò significa che un servizio di gestione dei reclami non può esistere senza un microservizio *Customers*. *Le vendite* e *i clienti* sono raggruppati in un unico pacchetto di microservizi e una transazione commerciale richiede il coordinamento con entrambi.
# Modello di servizio per team
Invece di scomporre i monoliti in base alle funzionalità o ai servizi aziendali, il modello service per team li suddivide in microservizi gestiti da singoli team. Ogni team è responsabile di una funzionalità aziendale e possiede il codice base della funzionalità. Il team sviluppa, testa, implementa o ridimensiona i propri servizi in modo indipendente e interagisce principalmente con altri team per negoziare. APIs Ti consigliamo di assegnare ogni microservizio a un singolo team. Tuttavia, se il team è sufficientemente numeroso, più sottogruppi potrebbero possedere microservizi separati all'interno della stessa struttura del team. La tabella seguente illustra i vantaggi e gli svantaggi dell'utilizzo di questo modello.
****
| Vantaggi | Svantaggi |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/service-per-team.html) |
L'illustrazione seguente mostra come un monolite può essere suddiviso in microservizi gestiti, mantenuti e forniti da singoli team.
![\[Scomposizione dei monoliti in microservizi da parte dei team\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/service-per-team.png)
# Motivo a fico Strangler
I modelli di progettazione discussi finora in questa guida si applicano alle applicazioni di scomposizione per progetti greenfield. Che dire dei progetti dismessi che coinvolgono applicazioni monolitiche di grandi dimensioni? Applicarvi i modelli di progettazione precedenti sarà difficile, perché suddividerli in pezzi più piccoli mentre vengono utilizzati attivamente è un compito arduo.
Il [motivo a fichi strangolatori](https://martinfowler.com/bliki/StranglerFigApplication.html) è un modello di design popolare introdotto da Martin Fowler, che si è ispirato a un certo tipo di fico che si semina tra i rami superiori degli alberi. L'albero esistente diventa inizialmente una struttura di supporto per il nuovo fico. Il fico poi affonda le sue radici al suolo, avvolgendo gradualmente l'albero originale e lasciando al suo posto solo il nuovo fico autoportante.
Questo modello viene comunemente utilizzato per trasformare in modo incrementale un'applicazione monolitica in microservizi sostituendo una particolare funzionalità con un nuovo servizio. L'obiettivo è far coesistere la versione precedente e quella nuova e modernizzata. Il nuovo sistema è inizialmente supportato dal sistema esistente e lo integra. Questo supporto dà al nuovo sistema il tempo necessario per crescere e potenzialmente sostituire completamente il vecchio sistema.
Il processo di transizione da un'applicazione monolitica ai microservizi mediante l'implementazione del pattern strangler fig prevede tre fasi: trasformazione, coesistenza ed eliminazione:
+ *Trasformazione*: identifica e crea componenti modernizzati portandoli o riscrivendoli in parallelo con l'applicazione precedente.
+ *Coesistenza*: mantieni l'applicazione monolitica per il rollback. Intercetta le chiamate di sistema esterne incorporando un proxy HTTP (ad esempio [Amazon API Gateway](https://docs.aws.amazon.com/apigateway/latest/developerguide/welcome.html)) sul perimetro del monolite e reindirizza il traffico verso la versione modernizzata. Questo ti aiuta a implementare le funzionalità in modo incrementale.
+ *Eliminazione: elimina* le vecchie funzionalità dal monolite poiché il traffico viene reindirizzato dal monolite precedente al servizio modernizzato.
La tabella seguente illustra i vantaggi e gli svantaggi dell'utilizzo del pattern Strangler Fig.
****
| Vantaggi | Svantaggi |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/strangler-fig.html) |
L'illustrazione seguente mostra come un monolite può essere suddiviso in microservizi applicando lo strangler fig pattern a un'architettura applicativa. Entrambi i sistemi funzionano in parallelo, ma inizierai a spostare le funzionalità al di fuori del codice base di Monolith e a migliorarla con nuove funzionalità. Queste nuove funzionalità ti offrono l'opportunità di progettare i microservizi nel modo più adatto alle tue esigenze. Continuerai a eliminare le funzionalità dal monolite finché non saranno tutte sostituite dai microservizi. A quel punto, puoi eliminare l'applicazione Monolith. Il punto chiave da notare qui è che sia il monolite che i microservizi vivranno insieme per un periodo di tempo.
![\[Scomposizione dei monoliti in microservizi utilizzando lo schema Strangler Fig\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/strangler-fig.png)
# Ramo per modello di astrazione
Lo schema Strangler Fig funziona bene quando è possibile intercettare le chiamate sul perimetro del monolite. Tuttavia, se desideri modernizzare i componenti che esistono più a fondo nello stack di applicazioni legacy e hanno dipendenze a monte, ti consigliamo il pattern branch by abstraction. Questo modello consente di apportare modifiche alla base di codice esistente per consentire alla versione modernizzata di coesistere in sicurezza con la versione precedente senza causare interruzioni.
Per utilizzare correttamente il pattern branch by abstraction, segui questa procedura:
1. Identifica i componenti monolitici che hanno dipendenze a monte.
1. Crea un livello di astrazione che rappresenti le interazioni tra il codice da modernizzare e i suoi client.
1. Una volta completata l'astrazione, modifica i client esistenti per utilizzare la nuova astrazione.
1. Crea una nuova implementazione dell'astrazione con la funzionalità rielaborata all'esterno del monolite.
1. Passa l'astrazione alla nuova implementazione quando sei pronto.
1. Quando la nuova implementazione fornisce tutte le funzionalità necessarie agli utenti e il monolite non è più in uso, pulisci l'implementazione precedente.
Il pattern branch by abstraction viene spesso confuso con i [feature toggles](http://martinfowler.com/bliki/FeatureToggle.html), che consentono inoltre di apportare modifiche al sistema in modo incrementale. La differenza è che i feature toggle hanno lo scopo di consentire lo sviluppo di nuove funzionalità e mantenerle invisibili agli utenti quando il sistema è in esecuzione. I feature toggle vengono quindi utilizzati in fase di implementazione o in fase di esecuzione per scegliere se una particolare funzionalità o un insieme di funzionalità sono visibili nell'applicazione. Branch by abstraction è una tecnica di sviluppo e può essere combinata con feature toggles per passare dalla vecchia alla nuova implementazione.
La tabella seguente spiega i vantaggi e gli svantaggi dell'utilizzo del pattern branch by abstraction.
****
| Vantaggi | Svantaggi |
| --- | --- |
| [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html) | [\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/branch-by-abstraction.html) |
L'illustrazione seguente mostra il modello di astrazione, diramato per astrazione, di un componente *Notification* nel monolite assicurativo. Inizia con la creazione di un abstract o di un'interfaccia per la funzionalità di notifica. In piccoli incrementi, i client esistenti vengono modificati per utilizzare la nuova astrazione. Ciò potrebbe richiedere la ricerca nella codebase di chiamate APIs relative al componente *Notification*. Create la nuova implementazione della funzionalità di notifica come microservizio all'esterno del vostro monolite e la ospitate nell'architettura modernizzata. All'interno del monolite, l'interfaccia di astrazione appena creata funge da broker e richiama la nuova implementazione. In piccoli incrementi, trasferisci la funzionalità di notifica alla nuova implementazione, che rimane inattiva fino a quando non è completamente testata e pronta. Quando la nuova implementazione è pronta, sostituisci l'astrazione per utilizzarla. Ti consigliamo di utilizzare un meccanismo di commutazione che possa essere invertito facilmente (come un interruttore di funzionalità) in modo da poter tornare facilmente alla vecchia funzionalità in caso di problemi. Quando la nuova implementazione inizia a fornire tutte le funzionalità di notifica agli utenti e il monolite non è più in uso, potete ripulire l'implementazione precedente e rimuovere qualsiasi indicatore di funzionalità di commutazione che potreste aver implementato
![\[Scomposizione dei monoliti in microservizi utilizzando il pattern branch by abstraction\]](http://docs.aws.amazon.com/it_it/prescriptive-guidance/latest/modernization-decomposing-monoliths/images/branch-by-abstraction.png)