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à.
# Altre considerazioni
Finora, abbiamo discusso dell'utilizzo di API Gateway e contenitori Windows per modernizzare i servizi Web ASP.NET legacy su. AWS Ecco alcune altre considerazioni da tenere in considerazione:
+ Sicurezza
+ Rimodellamento dei domini di servizio
+ Sequenziamento degli aggiornamenti dei servizi web quando ci sono molti servizi da modernizzare
Questi dettagli vengono illustrarti nelle sezioni seguenti.
## Autenticazione e autorizzazione
I moderni APIs generalmente utilizzano standard di autenticazione e autorizzazione basati su token (JSON Web Token o JWT) come 2.0 e OAuth OpenID Connect, mentre i servizi Web ASP.NET legacy si basavano tradizionalmente sull'autenticazione di base o sull'autenticazione integrata di Windows su un dominio Windows Active Directory. Come best practice, nei casi in cui i vecchi e nuovi approcci di autenticazione e autorizzazione siano incompatibili, si consiglia di aggiornare questi meccanismi di sicurezza prima di modernizzare il servizio Web. AWS Il tentativo di mappare le identità o di trasferire in modo sicuro lo stato di sicurezza tra il vecchio e il nuovo sistema potrebbe non essere uno sforzo significativo, ma potrebbe introdurre vulnerabilità di sicurezza.
## Progettazione basata sul dominio
Quando si suddivide un monolite nei singoli servizi, la progettazione basata sul dominio (DDD) è una best practice che viene spesso utilizzata per modellare i sistemi in domini aziendali coesi. DDD è un approccio allo sviluppo di software per esigenze complesse che collega l'implementazione a un modello in evoluzione dei concetti aziendali principali. La sua premessa è porre l'attenzione principale del progetto sul dominio principale e sulla logica di dominio e basare la progettazione del sistema su un modello che rifletta il business. Se si utilizza DDD per modernizzare un'applicazione monolitica esistente, è necessario lavorare a ritroso partendo dalle funzionalità e dai flussi di utenti del monolite. *È possibile utilizzare DDD in combinazione con lo strangler Pattern per guidare il processo di rottura del monolite e determinare quali servizi strangolare, da cui il termine domain-driven design.*
## Stati provvisori e stato di destinazione
Quando si modernizzano più di alcuni servizi Web ASP.NET AWS, è buona norma definire innanzitutto quale sarà l'architettura dello stato di destinazione dopo la modernizzazione di tutti i servizi. Tuttavia, l'architettura dello stato di destinazione non è necessariamente lo stato finale o lo stato finale, poiché i contesti aziendali cambiano spesso e lo stato di destinazione del sistema deve essere aggiornato secondo necessità per rimanere in linea con gli obiettivi aziendali. Una volta definito lo stato di destinazione, è possibile procedere a ritroso per definire architetture provvisorie che soddisfino in modo incrementale la visione dello stato di destinazione. Potete pensare a queste architetture ad interim come alla progressione della vite di fico strangolatore che risale l'albero mentre incontra e avvolge porzioni principali dell'albero che lo ospita. Le architetture con stati provvisori spesso introducono costrutti temporanei o sovrapposti che non faranno parte dell'architettura dello stato finale per facilitare l'evoluzione verso lo stato di destinazione. La modernizzazione del servizio Web ASP.NET basato su SOAP ne fornisce un esempio: viene introdotto temporaneamente un contenitore basato su Windows per colmare il divario tra i sistemi di chiamata che dipendono dal servizio legacy fino a quando non possono essere aggiornati alla nuova API REST.