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à.

# Modello di servizio per team
<a name="service-per-team"></a>

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)