Altre considerazioni

Finora, abbiamo discusso dell'utilizzo di API Gateway e contenitori Windows per modernizzare i servizi Web ASP.NET legacy suAWS. È necessario tenere conto delle considerazioni seguenti:

• Sicurezza

• Rimodellamento dei domini dei servizi

• Sequenziamento degli aggiornamenti dei servizi Web quando sono presenti molti servizi da modernizzare

Questi dettagli vengono illustrarti nelle sezioni seguenti.

Autenticazione e autorizzazione

Le API moderne in genere sfruttano standard di autenticazione e autorizzazione basati su token (JSON Web Token o JWT) come OAuth 2.0 e OpenID Connect, mentre i servizi Web ASP.NET legacy si basavano tradizionalmente sull'autenticazione di base o sull'autenticazione integrata con Windows in un dominio Windows Active Directory. Come best practice, nei casi in cui i vecchi e nuovi approcci di autenticazione e autorizzazione sono incompatibili, ti consigliamo di aggiornare questi meccanismi di sicurezza prima di modernizzare il tuo servizio webAWS. Tentare di mappare le identità o cercare di trasferire in modo sicuro lo stato di sicurezza tra i vecchi e i nuovi sistemi potrebbe non essere uno sforzo significativo, ma potrebbe introdurre vulnerabilità di sicurezza.

Progettazione basata sul dominio

Quando si suddivide un monolite in singoli servizi, la progettazione guidata dal dominio (DDD) è una best practice che viene spesso utilizzata per modellare i sistemi in domini aziendali coesi. Il DDD è un approccio allo sviluppo di software per esigenze complesse che collega l'implementazione a un modello in evoluzione dei concetti aziendali fondamentali. La sua premessa è porre l'attenzione principale del progetto sul dominio principale e sulla logica di dominio e basare la progettazione dei sistemi su un modello che rifletta il business. Se usi DDD quando modernizzi un'applicazione monolitica esistente, devi lavorare a ritroso rispetto alle funzionalità e ai flussi di utenti del monolite. È possibile utilizzare il DDD in combinazione con il pattern strangolatore per guidare il processo di rottura del monolite e determinare quali servizi strangolare, da cui il termine progettazione guidata dal dominio.

Stati ad interim e stato bersaglio

Quando si stanno modernizzando più di pochi servizi Web ASP.NETAWS, è 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. Dopo aver definito lo stato di destinazione, è possibile lavorare a ritroso da lì per definire architetture intermedie che soddisfino in modo incrementale la visione dello stato di destinazione. Potete pensare a queste architetture dello stato provvisorio come alla progressione del fico strangolatore che si arrampica sull'albero mentre incontra e inghiotte le porzioni principali dell'albero ospite. Le architetture degli stati provvisori spesso introducono costrutti temporanei o sovrapposti che non faranno parte dell'architettura dello stato finale per facilitare l'evoluzione verso lo stato bersaglio. La modernizzazione del servizio web ASP.NET basato su SOAP ne fornisce un esempio: un contenitore basato su Windows viene introdotto temporaneamente 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.