Outras considerações

Até agora, discutimos o uso do API Gateway e dos contêineres do Windows para modernizar seus serviços web antigos do ASP.NET noAWS. Aqui estão algumas outras considerações a serem consideradas:

• Segurança

• Remodelação de domínios de serviço

• Sequenciando atualizações de serviços web quando há muitos serviços a serem modernizados

Esses são discutidos nas seções a seguir.

Autenticação e autorização

As APIs modernas geralmente utilizam padrões de autenticação e autorização baseados em tokens (JSON Web Token ou JWT), como OAuth 2.0 e OpenID Connect, enquanto os serviços web antigos do ASP.NET tradicionalmente dependiam da autenticação básica ou da autenticação integrada ao Windows em um domínio do Windows Active Directory. Como prática recomendada, nos casos em que as abordagens de autenticação e autorização antigas e novas sejam incompatíveis, recomendamos que você atualize esses mecanismos de segurança antes de modernizar seu serviço webAWS. Tentar mapear identidades ou tentar transferir com segurança o estado de segurança entre os sistemas antigos e novos pode não ser um esforço significativo, mas pode introduzir vulnerabilidades de segurança.

Design orientado por domínio

Ao dividir um monólito em serviços individuais, o design orientado por domínio (DDD) é uma prática recomendada que geralmente é usada para modelar sistemas em domínios de negócios coesos. O DDD é uma abordagem para o desenvolvimento de software para necessidades complexas, conectando a implementação a um modelo em evolução dos principais conceitos de negócios. Sua premissa é colocar o foco principal do projeto no domínio central e na lógica do domínio e basear os projetos do sistema em um modelo que reflita o negócio. Se você usa o DDD ao modernizar um aplicativo monolítico existente, precisará retroceder a partir dos recursos e dos fluxos de usuário do monólito. Você pode usar o DDD em combinação com o padrão estrangulador para orientar o processo de quebra do monólito e determinar quais serviços estrangular, daí o termo design orientado por domínio.

Estados provisórios e estado alvo

Quando você está modernizando mais do que alguns serviços web do ASP.NETAWS, é uma boa prática definir primeiro qual será sua arquitetura de estado de destino depois que todos os serviços forem modernizados. No entanto, a arquitetura do estado alvo não é necessariamente o estado final ou o estado final, porque os contextos de negócios mudam com frequência e o estado alvo do sistema deve ser atualizado conforme necessário para permanecer alinhado com as metas de negócios. Depois de definir o estado alvo, você pode retroceder a partir daí para definir arquiteturas de estado provisório que cumpram incrementalmente a visão do estado alvo. Você pode pensar nessas arquiteturas de estado provisório como a progressão da figueira estranguladora até a árvore ao encontrar e engolir grandes porções da árvore hospedeira. As arquiteturas de estado provisório geralmente introduzem construções temporárias ou sobrepostas que não farão parte da arquitetura do estado final para facilitar a evolução para o estado alvo. A modernização do serviço web ASP.NET baseado em SOAP fornece um exemplo disso: um contêiner baseado em Windows é introduzido temporariamente para preencher a lacuna entre os sistemas de chamada que dependem do serviço legado até que possam ser atualizados para a nova API REST.